doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc7126.txt b/doc/rfc/rfc7126.txt
new file mode 100644
index 0000000..90a1b8c
--- /dev/null
+++ b/doc/rfc/rfc7126.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           F. Gont
+Request for Comments: 7126                        UTN-FRH / SI6 Networks
+BCP: 186                                                     R. Atkinson
+Category: Best Current Practice                               Consultant
+ISSN: 2070-1721                                             C. Pignataro
+                                                                   Cisco
+                                                           February 2014
+
+
+  Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
+
+Abstract
+
+   This document provides advice on the filtering of IPv4 packets based
+   on the IPv4 options they contain.  Additionally, it discusses the
+   operational and interoperability implications of dropping packets
+   based on the IP options they contain.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Further information on BCPs is
+   available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7126.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 1]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Terminology and Conventions Used in This Document . . . .   3
+     1.2.  Operational Focus . . . . . . . . . . . . . . . . . . . .   4
+   2.  IP Options  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  General Security Implications of IP Options . . . . . . . . .   5
+     3.1.  Processing Requirements . . . . . . . . . . . . . . . . .   5
+   4.  Advice on the Handling of Packets with Specific IP Options  .   7
+     4.1.  End of Option List (Type = 0) . . . . . . . . . . . . . .   7
+     4.2.  No Operation (Type = 1) . . . . . . . . . . . . . . . . .   7
+     4.3.  Loose Source and Record Route (LSRR) (Type = 131) . . . .   8
+     4.4.  Strict Source and Record Route (SSRR) (Type = 137)  . . .  10
+     4.5.  Record Route (Type = 7) . . . . . . . . . . . . . . . . .  11
+     4.6.  Stream Identifier (Type = 136) (obsolete) . . . . . . . .  12
+     4.7.  Internet Timestamp (Type = 68)  . . . . . . . . . . . . .  13
+     4.8.  Router Alert (Type = 148) . . . . . . . . . . . . . . . .  14
+     4.9.  Probe MTU (Type = 11) (obsolete)  . . . . . . . . . . . .  15
+     4.10. Reply MTU (Type = 12) (obsolete)  . . . . . . . . . . . .  16
+     4.11. Traceroute (Type = 82)  . . . . . . . . . . . . . . . . .  16
+     4.12. DoD Basic Security Option (Type = 130)  . . . . . . . . .  17
+     4.13. DoD Extended Security Option (Type = 133) . . . . . . . .  20
+     4.14. Commercial IP Security Option (CIPSO) (Type = 134)  . . .  22
+     4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . .  23
+     4.16. Extended Internet Protocol (Type = 145) . . . . . . . . .  24
+     4.17. Address Extension (Type = 147)  . . . . . . . . . . . . .  25
+     4.18. Sender Directed Multi-Destination Delivery (Type = 149) .  25
+     4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . .  26
+     4.20. Upstream Multicast Pkt. (Type = 152)  . . . . . . . . . .  26
+     4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . .  27
+     4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) .  28
+     4.23. Other IP Options  . . . . . . . . . . . . . . . . . . . .  29
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 2]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+1.  Introduction
+
+   This document discusses the filtering of IPv4 packets based on the
+   IPv4 options they contain.  Since various protocols may use IPv4
+   options to some extent, dropping packets based on the options they
+   contain may have implications on the proper functioning of such
+   protocols.  Therefore, this document attempts to discuss the
+   operational and interoperability implications of such dropping.
+   Additionally, it outlines what a network operator might do in typical
+   enterprise or Service Provider environments.  This document also
+   draws and is partly derived from [RFC6274], which also received
+   review from the operational community.
+
+   We note that data seems to indicate that there is a current
+   widespread practice of blocking IPv4 optioned packets.  There are
+   various plausible approaches to minimize the potential negative
+   effects of IPv4 optioned packets while allowing some option
+   semantics.  One approach is to allow for specific options that are
+   expected or needed, and have a default deny.  A different approach is
+   to deny unneeded options and have a default allow.  Yet a third
+   possible approach is to allow for end-to-end semantics by ignoring
+   options and treating packets as un-optioned while in transit.
+   Experiments and currently available data tend to support the first or
+   third approaches as more realistic.  Some results regarding the
+   current state of affairs with respect to dropping packets containing
+   IP options can be found in [MEDINA] and [FONSECA].  Additionally,
+   [BREMIER-BARR] points out that the deployed Internet already has many
+   routers that do not process IP options.
+
+   We also note that while this document provides advice on dropping
+   packets on a "per IP option type", not all devices (routers, security
+   gateways, and firewalls) may provide this capability with such
+   granularity.  Additionally, even in cases in which such functionality
+   is provided, an operator might want to specify a dropping policy with
+   a coarser granularity (rather than on a "per IP option type"
+   granularity), as indicated above.
+
+   Finally, in scenarios in which processing of IP options by
+   intermediate systems is not required, a widespread approach is to
+   simply ignore IP options and process the corresponding packets as if
+   they do not contain any IP options.
+
+1.1.  Terminology and Conventions Used in This Document
+
+   The terms "fast path", "slow path", and associated relative terms
+   ("faster path" and "slower path") are loosely defined as in Section 2
+   of [RFC6398].
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 3]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   Because of the security-oriented nature of this document, we are
+   deliberately including some historical citations.  The goal is to
+   explicitly retain and show history, as well as remove ambiguity and
+   confusion.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2.  Operational Focus
+
+   All of the recommendations in this document have been made in an
+   effort to optimize for operational community consensus, as best the
+   authors have been able to determine that.  This has included not only
+   accepting feedback from public lists, but also accepting off-list
+   feedback from people at various network operators (e.g. Internet
+   Service Providers, content providers, educational institutions,
+   commercial firms).
+
+2.  IP Options
+
+   IP options allow for the extension of the Internet Protocol.  As
+   specified in [RFC0791], 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.
+
+   IP options of Case 1 have the following syntax:
+
+   +-+-+-+-+-+-+-+-+- - - - - - - - -
+   |  option-type  |  option-data
+   +-+-+-+-+-+-+-+-+- - - - - - - - -
+
+   The length of IP options of Case 1 is implicitly specified by the
+   option-type byte.
+
+   IP options of Case 2 have the following syntax:
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+   |  option-type  | option-length |  option-data
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+
+   In this case, the option-length byte counts the option-type byte and
+   the option-length byte, as well as the actual option-data bytes.
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 4]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   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.
+
+   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.
+
+   This format allows for the creation of new options for the extension
+   of the Internet Protocol (IP).
+
+   Finally, the option number identifies the syntax of the rest of the
+   option.
+
+   The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the
+   currently assigned IP option numbers.
+
+3.  General Security Implications of IP Options
+
+3.1.  Processing Requirements
+
+   Historically, most IP routers used a general-purpose CPU to process
+   IP packets and forward them towards their destinations.  This same
+   CPU usually also processed network management traffic (e.g., SNMP),
+   configuration commands (e.g., command line interface), and various
+   routing protocols (e.g., RIP, OSPF, BGP, IS-IS) or other control
+   protocols (e.g., RSVP, ICMP).  In such architectures, it has been
+   common for the general-purpose CPU also to perform any packet
+
+
+
+Gont, et al.              Best Current Practice                 [Page 5]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   filtering that has been enabled on the router (or router interface).
+   An IP router built using this architecture often has a significant
+   Distributed Denial-of-Service (DDoS) attack risk if the router
+   control plane (e.g., CPU) is overwhelmed by a large number of IPv4
+   packets that contain IPv4 options.
+
+   From about 1995 onwards, a growing number of IP routers have
+   incorporated silicon specialized for IP packet processing (i.e.,
+   Field-Programmable Gate Array (FPGA), Application-Specific Integrated
+   Circuit (ASIC)), thereby separating the function of IP packet
+   forwarding from the other functions of the router.  Such router
+   architectures tend to be more resilient to DDoS attacks that might be
+   seen in the global public Internet.  Depending upon various
+   implementation and configuration details, routers with a silicon
+   packet-forwarding engine can handle high volumes of IP packets
+   containing IP options without any adverse impact on packet-forwarding
+   rates or on the router's control plane (e.g., general-purpose CPU).
+   Some implementations have a configuration knob simply to forward all
+   IP packets containing IP options at wire-speed in silicon, as if the
+   IP packet did not contain any IP options ("ignore options &
+   forward").  Other implementations support wire-speed silicon-based
+   packet filtering, thereby enabling packets containing certain IP
+   options to be selectively dropped ("drop"), packets containing
+   certain other IP options to have those IP options ignored ("ignore
+   options & forward"), and other packets containing different IP
+   options to have those options processed, either on a general-purpose
+   CPU or using custom logic (e.g., FPGA, ASIC), while the packet is
+   being forwarded ("process option & forward").
+
+   Broadly speaking, any IP packet that requires processing by an IP
+   router's general-purpose CPU can be a DDoS risk to that router's
+   general-purpose CPU (and thus to the router itself).  However, at
+   present, the particular architectural and engineering details of the
+   specific IP router being considered are important to understand when
+   evaluating the operational security risks associated with a
+   particular IP packet type or IP option type.
+
+   Operators are urged to consider the capabilities of potential IP
+   routers for IP option filtering and handling as they make deployment
+   decisions in the future.
+
+   Additional considerations for protecting the control plane from
+   packets containing IP options can be found in [RFC6192].
+
+   Finally, in addition to advice to operators, this document also
+   provides advice to router, security gateway, and firewall
+   implementers in terms of providing the capability to filter packets
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 6]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   with different granularities: both on a "per IP option type"
+   granularity (to maximize flexibility) as well as more coarse filters
+   (to minimize configuration complexity).
+
+4.  Advice on the Handling of Packets with Specific IP Options
+
+   The following subsections contain a description of each of the IP
+   options that have so far been specified, a discussion of possible
+   interoperability implications if packets containing such options are
+   dropped, and specific advice on whether to drop packets containing
+   these options in a typical enterprise or Service Provider
+   environment.
+
+4.1.  End of Option List (Type = 0)
+
+4.1.1.  Uses
+
+   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.
+
+4.1.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791].
+
+4.1.3.  Threats
+
+   No specific security issues are known for this IPv4 option.
+
+4.1.4.  Operational and Interoperability Impact if Blocked
+
+   Packets containing any IP options are likely to include an End of
+   Option List.  Therefore, if packets containing this option are
+   dropped, it is very likely that legitimate traffic is blocked.
+
+4.1.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD NOT drop packets
+   because they contain this option.
+
+4.2.  No Operation (Type = 1)
+
+4.2.1.  Uses
+
+   The no-operation option is basically meant to allow the sending
+   system to align subsequent options in, for example, 32-bit
+   boundaries.
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 7]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.2.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791].
+
+4.2.3.  Threats
+
+   No specific security issues are known for this IPv4 option.
+
+4.2.4.  Operational and Interoperability Impact if Blocked
+
+   Packets containing any IP options are likely to include a No
+   Operation option.  Therefore, if packets containing this option are
+   dropped, it is very likely that legitimate traffic is blocked.
+
+4.2.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD NOT drop packets
+   because they contain this option.
+
+4.3.  Loose Source and Record Route (LSRR) (Type = 131)
+
+   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).
+
+4.3.1.  Uses
+
+   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 Internet Service Provider (ISP) peering agreements require
+   support for this option in the routers within the peer of the ISP.
+
+4.3.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791].
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 8]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.3.3.  Threats
+
+   The LSRR option has well-known security implications [RFC6274].
+   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 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.
+
+   Additionally, some implementations have been found to fail to include
+   proper sanity checks on the LSRR option, thus leading to security
+   issues.  These specific issues are believed to be solved in all
+   modern implementations.
+
+      [Microsoft1999] is a security advisory about a vulnerability
+      arising from improper validation of the Pointer field of the LSRR
+      option.
+
+   Finally, we note that some systems were known for providing a system-
+   wide toggle to enable support for this option for those scenarios in
+   which this option is required.  However, improper implementation of
+   such a system-wide toggle caused those systems to support the LSRR
+   option even when explicitly configured not to do so.
+
+      [OpenBSD1998] is a security advisory about an improper
+      implementation of such a system-wide toggle in 4.4BSD kernels.
+      This issue was resolved in later versions of the corresponding
+      operating system.
+
+
+
+
+Gont, et al.              Best Current Practice                 [Page 9]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.3.4.  Operational and Interoperability Impact if Blocked
+
+   Network troubleshooting techniques that may employ the LSRR option
+   (such as ping or traceroute with the appropriate arguments) would
+   break when using the LSRR option.  (Ping and traceroute without IPv4
+   options are not impacted.)  Nevertheless, it should be noted that it
+   is virtually impossible to use the LSRR option for troubleshooting,
+   due to widespread dropping of packets that contain the option.
+
+4.3.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD implement an option-
+   specific configuration knob to select whether packets with this
+   option are dropped, packets with this IP option are forwarded as if
+   they did not contain this IP option, or packets with this option are
+   processed and forwarded as per [RFC0791].  The default setting for
+   this knob SHOULD be "drop", and the default setting MUST be
+   documented.
+
+   Please note that treating packets with LSRR as if they did not
+   contain this option can result in such packets being sent to a
+   different device than the initially intended destination.  With
+   appropriate ingress filtering, this should not open an attack vector
+   into the infrastructure.  Nonetheless, it could result in traffic
+   that would never reach the initially intended destination.  Dropping
+   these packets prevents unnecessary network traffic and does not make
+   end-to-end communication any worse.
+
+4.4.  Strict Source and Record Route (SSRR) (Type = 137)
+
+4.4.1.  Uses
+
+   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 SSRR option can be of help in debugging some network problems.
+   Some ISP peering agreements require support for this option in the
+   routers within the peer of the ISP.
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 10]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.4.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791].
+
+4.4.3.  Threats
+
+   The SSRR option has the same security implications as the LSRR
+   option.  Please refer to Section 4.3 for a discussion of such
+   security implications.
+
+4.4.4.  Operational and Interoperability Impact if Blocked
+
+   Network troubleshooting techniques that may employ the SSRR option
+   (such as ping or traceroute with the appropriate arguments) would
+   break when using the SSRR option.  (Ping and traceroute without IPv4
+   options are not impacted.)  Nevertheless, it should be noted that it
+   is virtually impossible to use the SSRR option for trouble-shooting,
+   due to widespread dropping of packets that contain such option.
+
+4.4.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD implement an option-
+   specific configuration knob to select whether packets with this
+   option are dropped, packets with this IP option are forwarded as if
+   they did not contain this IP option, or packets with this option are
+   processed and forwarded as per [RFC0791].  The default setting for
+   this knob SHOULD be "drop", and the default setting MUST be
+   documented.
+
+   Please note that treating packets with SSRR as if they did not
+   contain this option can result in such packets being sent to a
+   different device that the initially intended destination.  With
+   appropriate ingress filtering this should not open an attack vector
+   into the infrastructure.  Nonetheless, it could result in traffic
+   that would never reach the initially intended destination.  Dropping
+   these packets prevents unnecessary network traffic, and does not make
+   end-to-end communication any worse.
+
+4.5.  Record Route (Type = 7)
+
+4.5.1.  Uses
+
+   This option provides a means to record the route that a given packet
+   follows.
+
+4.5.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791].
+
+
+
+Gont, et al.              Best Current Practice                [Page 11]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.5.3.  Threats
+
+   This option can be exploited to map the topology of a network.
+   However, the limited space in the IP header limits the usefulness of
+   this option for that purpose.
+
+4.5.4.  Operational and Interoperability Impact if Blocked
+
+   Network troubleshooting techniques that may employ the RR option
+   (such as ping with the RR option) would break when using the RR
+   option.  (Ping without IPv4 options is not impacted.)  Nevertheless,
+   it should be noted that it is virtually impossible to use such
+   techniques due to widespread dropping of packets that contain RR
+   options.
+
+4.5.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD implement an option-
+   specific configuration knob to select whether packets with this
+   option are dropped, packets with this IP option are forwarded as if
+   they did not contain this IP option, or packets with this option are
+   processed and forwarded as per [RFC0791].  The default setting for
+   this knob SHOULD be "drop", and the default setting MUST be
+   documented.
+
+4.6.  Stream Identifier (Type = 136) (obsolete)
+
+   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 3.2.1.8 of RFC 1122 [RFC1122] and
+   Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete.
+   Therefore, it must be ignored by the processing systems.  See also
+   [IANA-IP] and [RFC6814].
+
+   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).
+
+4.6.1.  Uses
+
+   This option is obsolete.  There is no current use for this option.
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 12]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.6.2.  Option Specification
+
+   Specified in RFC 791 [RFC0791], and deprecated in RFC 1122 [RFC1122]
+   and RFC 1812 [RFC1812].  This option has been formally obsoleted by
+   [RFC6814].
+
+4.6.3.  Threats
+
+   No specific security issues are known for this IPv4 option.
+
+4.6.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.6.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets
+   containing a Stream Identifier option.
+
+4.7.  Internet Timestamp (Type = 68)
+
+4.7.1.  Uses
+
+   This option provides a means for recording the time at which each
+   system (or a specified set of systems) processed this datagram, and
+   it may optionally record the addresses of the systems providing the
+   timestamps.
+
+4.7.2.  Option Specification
+
+   Specified by RFC 791 [RFC0791].
+
+4.7.3.  Threats
+
+   The timestamp option has a number of security implications [RFC6274].
+   Among them are:
+
+   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.
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 13]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   o  It may be used to fingerprint physical devices by analyzing the
+      clock skew.
+
+   [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.
+
+4.7.4.  Operational and Interoperability Impact if Blocked
+
+   Network troubleshooting techniques that may employ the Internet
+   Timestamp option (such as ping with the Timestamp option) would break
+   when using the Timestamp option.  (Ping without IPv4 options is not
+   impacted.)  Nevertheless, it should be noted that it is virtually
+   impossible to use such techniques due to widespread dropping of
+   packets that contain Internet Timestamp options.
+
+4.7.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets
+   containing an Internet Timestamp option.
+
+4.8.  Router Alert (Type = 148)
+
+4.8.1.  Uses
+
+   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".
+
+4.8.2.  Option Specification
+
+   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]).
+
+4.8.3.  Threats
+
+   The security implications of the Router Alert option have been
+   discussed in detail in [RFC6398].  Basically, the Router Alert option
+   might be exploited to perform a DoS attack by exhausting CPU
+   resources at the processing routers.
+
+4.8.4.  Operational and Interoperability Impact if Blocked
+
+   Applications that employ the Router Alert option (such as RSVP
+   [RFC2205]) would break.
+
+
+
+Gont, et al.              Best Current Practice                [Page 14]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.8.5.  Advice
+
+   This option SHOULD be allowed only in controlled environments, where
+   the option can be used safely.  [RFC6398] identifies some such
+   environments.  In unsafe environments, packets containing this option
+   SHOULD be dropped.
+
+   A given router, security gateway, or firewall system has no way of
+   knowing a priori whether this option is valid in its operational
+   environment.  Therefore, routers, security gateways, and firewalls
+   SHOULD, by default, ignore the Router Alert option.  Additionally,
+   routers, security gateways, and firewalls SHOULD have a configuration
+   setting that governs their reaction in the presence of packets
+   containing the Router Alert option.  This configuration setting
+   SHOULD allow to honor and process the option, ignore the option, or
+   drop packets containing this option.
+
+4.9.  Probe MTU (Type = 11) (obsolete)
+
+4.9.1.  Uses
+
+   This option originally provided a mechanism to discover the Path-MTU.
+   It has been declared obsolete.
+
+4.9.2.  Option Specification
+
+   This option was originally defined in RFC 1063 [RFC1063] and was
+   obsoleted with RFC 1191 [RFC1191].  This option is now obsolete, as
+   RFC 1191 obsoletes RFC 1063 without using IP options.
+
+4.9.3.  Threats
+
+   This option is obsolete.  This option could have been exploited to
+   cause a host to set its Path MTU (PMTU) estimate to an inordinately
+   low or an inordinately high value, thereby causing performance
+   problems.
+
+4.9.4.  Operational and Interoperability Impact if Blocked
+
+   None
+
+      This option is NOT employed with the modern "Path MTU Discovery"
+      (PMTUD) mechanism [RFC1191], which employs special ICMP messages
+      (Type 3, Code 4) in combination with the IP DF bit.  Packetization
+      Layer PMTUD (PLPMTUD) [RFC4821] can perform PMTUD without the need
+      for any special packets.
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 15]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.9.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets that
+   contain a Probe MTU option.
+
+4.10.  Reply MTU (Type = 12) (obsolete)
+
+4.10.1.  Uses
+
+   This option originally provided a mechanism to discover the Path-MTU.
+   It is now obsolete.
+
+4.10.2.  Option Specification
+
+   This option was originally defined in RFC 1063 [RFC1063] and was
+   obsoleted with RFC 1191 [RFC1191].  This option is now obsolete, as
+   RFC 1191 obsoletes RFC 1063 without using IP options.
+
+4.10.3.  Threats
+
+   This option is obsolete.  This option could have been exploited to
+   cause a host to set its PMTU estimate to an inordinately low or an
+   inordinately high value, thereby causing performance problems.
+
+4.10.4.  Operational and Interoperability Impact if Blocked
+
+   None
+
+      This option is NOT employed with the modern "Path MTU Discovery"
+      (PMTUD) mechanism [RFC1191], which employs special ICMP messages
+      (Type 3, Code 4) in combination with the IP DF bit.  PLPMTUD
+      [RFC4821] can perform PMTUD without the need of any special
+      packets.
+
+4.10.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets that
+   contain a Reply MTU option.
+
+4.11.  Traceroute (Type = 82)
+
+4.11.1.  Uses
+
+   This option originally provided a mechanism to trace the path to a
+   host.
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 16]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.11.2.  Option Specification
+
+   This option was originally specified by RFC 1393 [RFC1393] as
+   "experimental", and it was never widely deployed on the public
+   Internet.  This option has been formally obsoleted by [RFC6814].
+
+4.11.3.  Threats
+
+   This option is obsolete.  Because this option required each router in
+   the path both to provide special processing and to send an ICMP
+   message, it could have been exploited to perform a DoS attack by
+   exhausting CPU resources at the processing routers.
+
+4.11.4.  Operational and Interoperability Impact if Blocked
+
+   None
+
+4.11.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets that
+   contain a Traceroute option.
+
+4.12.  DoD Basic Security Option (Type = 130)
+
+4.12.1.  Uses
+
+   This option [RFC1108] is used by Multi-Level Secure (MLS) end-systems
+   and intermediate systems in specific environments to:
+
+   o  transmit from source to destination in a network standard
+      representation the common security labels required by computer
+      security models [Landwehr81],
+
+   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.
+
+   The DoD Basic Security Option (BSO) was implemented in IRIX
+   [IRIX2008] and is currently implemented in a number of operating
+   systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris
+   [Solaris2008], and Cisco IOS [Cisco-IPSO]).  It is also currently
+   deployed in a number of high-security networks.  These networks are
+   typically either in physically secure locations, protected by
+   military/governmental communications security equipment, or both.
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 17]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   Such networks are typically built using commercial off-the-shelf
+   (COTS) IP routers and Ethernet switches, but they are not normally
+   interconnected with the global public Internet.  MLS systems are much
+   more widely deployed now than they were at the time the then-IESG
+   decided to remove IPSO (IP Security Options) from the IETF Standards
+   Track.  Since nearly all MLS systems also support IPSO BSO and IPSO
+   ESO, this option is believed to have more deployment now than when
+   the IESG removed this option from the IETF Standards Track.
+   [RFC5570] describes a similar option recently defined for IPv6 and
+   has much more detailed explanations of how sensitivity label options
+   are used in real-world deployments.
+
+4.12.2.  Option Specification
+
+   It is specified by RFC 1108 [RFC1108], which obsoleted RFC 1038
+   [RFC1038] (which in turn obsoleted the Security Option defined in RFC
+   791 [RFC0791]).
+
+      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.  Later, RFC 1038 [RFC1038] revised the
+      IP security options, and in turn was obsoleted by RFC 1108
+      [RFC1108].  The "Security Option" specified in RFC 791 is
+      considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and
+      Section 4.2.2.1 of RFC 1812 [RFC1812], 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]".
+
+      Some private IP networks consider IP router-based per-interface
+      selective filtering of packets based on (a) the presence of an
+      IPSO option (including BSO and ESO) and (b) the contents of that
+      IPSO option to be important for operational security reasons.  The
+      recent IPv6 Common Architecture Label IPv6 Security Option
+      (CALIPSO) specification discusses this in additional detail,
+      albeit in an IPv6 context [RFC5570].
+
+      Such private IP networks commonly are built using both commercial
+      and open-source products -- for hosts, guards, firewalls,
+      switches, routers, etc.  Some commercial IP routers support this
+      option, as do some IP routers that are built on top of MLS
+      operating systems (e.g., on top of Trusted Solaris [Solaris2008]
+      or Security-Enhanced Linux [SELinux2008]).
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 18]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+      For example, many Cisco routers that run Cisco IOS include support
+      for selectively filtering packets that contain the IP Security
+      Options (IPSO) with per-interface granularity.  This capability
+      has been present in many Cisco routers since the early 1990s
+      [Cisco-IPSO-Cmds].  Some government-sector products reportedly
+      also support the IP Security Options (IPSO), for example, CANEWARE
+      [RFC4949].
+
+      Support for the IPSO Basic Security Option also is included in the
+      "IPsec Configuration Policy Information Model" [RFC3585] and in
+      the "IPsec Security Policy Database Configuration MIB" [RFC4807].
+      Section 4.6.1 of the IP Security Domain of Interpretation
+      [RFC2407] includes support for labeled IPsec security associations
+      compatible with the IP Security Options.  (Note: RFC 2407 was
+      obsoleted by [RFC4306], which was obsoleted by [RFC5996].)
+
+4.12.3.  Threats
+
+   Presence of this option in a packet does not by itself create any
+   specific new threat.  Packets with this option ought not normally be
+   seen on the global public Internet.
+
+4.12.4.  Operational and Interoperability Impact if Blocked
+
+   If packets with this option are blocked or if the option is stripped
+   from the packet during transmission from source to destination, then
+   the packet itself is likely to be dropped by the receiver because it
+   is not properly labeled.  In some cases, the receiver might receive
+   the packet but associate an incorrect sensitivity label with the
+   received data from the packet whose BSO was stripped by an
+   intermediate router or firewall.  Associating an incorrect
+   sensitivity label can cause the received information either to be
+   handled as more sensitive than it really is ("upgrading") or as less
+   sensitive than it really is ("downgrading"), either of which is
+   problematic.
+
+4.12.5.  Advice
+
+   A given IP router, security gateway, or firewall has no way to know a
+   priori what environment it has been deployed into.  Even closed IP
+   deployments generally use exactly the same commercial routers,
+   security gateways, and firewalls that are used in the public
+   Internet.
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 19]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   Since operational problems result in environments where this option
+   is needed if either the option is dropped or IP packets containing
+   this option are dropped, but no harm results if the option is carried
+   in environments where it is not needed, the default configuration
+   SHOULD NOT (a) modify or remove this IP option or (b) drop an IP
+   packet because the IP packet contains this option.
+
+   A given IP router, security gateway, or firewall MAY be configured to
+   drop this option or to drop IP packets containing this option in an
+   environment known to not use this option.
+
+   For auditing reasons, routers, security gateways, and firewalls
+   SHOULD be capable of logging the numbers of packets containing the
+   BSO on a per-interface basis.  Also, routers, security gateways, and
+   firewalls SHOULD be capable of dropping packets based on the BSO
+   presence as well as the BSO values.
+
+4.13.  DoD Extended Security Option (Type = 133)
+
+4.13.1.  Uses
+
+   This option permits additional security labeling information, beyond
+   that present in the Basic Security Option (Section 4.12), to be
+   supplied in an IP datagram to meet the needs of registered
+   authorities.
+
+4.13.2.  Option Specification
+
+   The DoD Extended Security Option (ESO) is specified by RFC 1108
+   [RFC1108].
+
+      Some private IP networks consider IP router-based per-interface
+      selective filtering of packets based on (a) the presence of an
+      IPSO option (including BSO and ESO) and (b) based on the contents
+      of that IPSO option to be important for operational security
+      reasons.  The recent IPv6 CALIPSO option specification discusses
+      this in additional detail, albeit in an IPv6 context [RFC5570].
+
+      Such private IP networks commonly are built using both commercial
+      and open-source products -- for hosts, guards, firewalls,
+      switches, routers, etc.  Some commercial IP routers support this
+      option, as do some IP routers that are built on top of MLS
+      operating systems (e.g., on top of Trusted Solaris [Solaris2008]
+      or Security-Enhanced Linux [SELinux2008]).
+
+      For example, many Cisco routers that run Cisco IOS include support
+      for selectively filtering packets that contain the IP Security
+      Options (IPSO) with per-interface granularity.  This capability
+
+
+
+Gont, et al.              Best Current Practice                [Page 20]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+      has been present in many Cisco routers since the early 1990s
+      [Cisco-IPSO-Cmds].  Some government sector products reportedly
+      also support the IP Security Options (IPSO), for example, CANEWARE
+      [RFC4949].
+
+      Support for the IPSO Extended Security Option also is included in
+      the "IPsec Configuration Policy Information Model" [RFC3585] and
+      in the "IPsec Security Policy Database Configuration MIB"
+      [RFC4807].  Section 4.6.1 of the IP Security Domain of
+      Interpretation [RFC2407] includes support for labeled IPsec
+      security associations compatible with the IP Security Options.
+
+4.13.3.  Threats
+
+   Presence of this option in a packet does not by itself create any
+   specific new threat.  Packets with this option ought not normally be
+   seen on the global public Internet.
+
+4.13.4.  Operational and Interoperability Impact if Blocked
+
+   If packets with this option are blocked or if the option is stripped
+   from the packet during transmission from source to destination, then
+   the packet itself is likely to be dropped by the receiver because it
+   is not properly labeled.  In some cases, the receiver might receive
+   the packet but associate an incorrect sensitivity label with the
+   received data from the packet whose ESO was stripped by an
+   intermediate router or firewall.  Associating an incorrect
+   sensitivity label can cause the received information either to be
+   handled as more sensitive than it really is ("upgrading") or as less
+   sensitive than it really is ("downgrading"), either of which is
+   problematic.
+
+4.13.5.  Advice
+
+   A given IP router, security gateway, or firewall has no way to know a
+   priori what environment it has been deployed into.  Even closed IP
+   deployments generally use exactly the same commercial routers,
+   security gateways, and firewalls that are used in the public
+   Internet.
+
+   Since operational problems result in environments where this option
+   is needed if either the option is dropped or IP packets containing
+   this option are dropped, but no harm results if the option is carried
+   in environments where it is not needed, the default configuration
+   SHOULD NOT (a) modify or remove this IP option or (b) drop an IP
+   packet because the IP packet contains this option.
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 21]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   A given IP router, security gateway, or firewall MAY be configured to
+   drop this option or to drop IP packets containing this option in an
+   environment known to not use this option.
+
+   For auditing reasons, routers, security gateways, and firewalls
+   SHOULD be capable of logging the numbers of packets containing the
+   ESO on a per-interface basis.  Also, routers, security gateways, and
+   firewalls SHOULD be capable of dropping packets based on the ESO
+   presence as well as the ESO values.
+
+4.14.  Commercial IP Security Option (CIPSO) (Type = 134)
+
+4.14.1.  Uses
+
+   This option was proposed by the Trusted Systems Interoperability
+   Group (TSIG), with the intent of meeting trusted networking
+   requirements for the commercial trusted systems marketplace.
+
+   It was implemented in IRIX [IRIX2008] and is currently implemented in
+   a number of operating systems (e.g., Security-Enhanced Linux
+   [SELinux2008] and Solaris [Solaris2008]).  It is also currently
+   deployed in a number of high-security networks.
+
+4.14.2.  Option Specification
+
+   This option is specified in [CIPSO] and [FIPS1994].  There are zero
+   known IP router implementations of CIPSO.  Several MLS operating
+   systems support CIPSO, generally the same MLS operating systems that
+   support IPSO.
+
+      The TSIG proposal was taken to the Commercial Internet Security
+      Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an
+      Internet-Draft was produced [CIPSO].  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].
+
+4.14.3.  Threats
+
+   Presence of this option in a packet does not by itself create any
+   specific new threat.  Packets with this option ought not normally be
+   seen on the global public Internet.
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 22]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.14.4.  Operational and Interoperability Impact if Blocked
+
+   If packets with this option are blocked or if the option is stripped
+   from the packet during transmission from source to destination, then
+   the packet itself is likely to be dropped by the receiver because it
+   is not properly labeled.  In some cases, the receiver might receive
+   the packet but associate an incorrect sensitivity label with the
+   received data from the packet whose CIPSO was stripped by an
+   intermediate router or firewall.  Associating an incorrect
+   sensitivity label can cause the received information either to be
+   handled as more sensitive than it really is ("upgrading") or as less
+   sensitive than it really is ("downgrading"), either of which is
+   problematic.
+
+4.14.5.  Advice
+
+   Because of the design of this option, with variable syntax and
+   variable length, it is not practical to support specialized filtering
+   using the CIPSO information.  No routers or firewalls are known to
+   support this option.  However, routers, security gateways, and
+   firewalls SHOULD NOT by default modify or remove this option from IP
+   packets and SHOULD NOT by default drop packets because they contain
+   this option.  For auditing reasons, routers, security gateways, and
+   firewalls SHOULD be capable of logging the numbers of packets
+   containing the CIPSO on a per-interface basis.  Also, routers,
+   security gateways, and firewalls SHOULD be capable of dropping
+   packets based on the CIPSO presence.
+
+4.15.  VISA (Type = 142)
+
+4.15.1.  Uses
+
+   This options was part of an experiment at the University of Southern
+   California (USC) and was never widely deployed.
+
+4.15.2.  Option Specification
+
+   The original option specification is not publicly available.  This
+   option has been formally obsoleted by [RFC6814].
+
+4.15.3.  Threats
+
+   Not possible to determine (other than the general security
+   implications of IP options discussed in Section 3), since the
+   corresponding specification is not publicly available.
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 23]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.15.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.15.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets that
+   contain this option.
+
+4.16.  Extended Internet Protocol (Type = 145)
+
+4.16.1.  Uses
+
+   The EIP option was introduced by one of the proposals submitted
+   during the IP Next Generation (IPng) efforts to address the problem
+   of IPv4 address exhaustion.
+
+4.16.2.  Option Specification
+
+   Specified in [RFC1385].  This option has been formally obsoleted by
+   [RFC6814].
+
+4.16.3.  Threats
+
+   This option is obsolete.  This option was used (or was intended to be
+   used) to signal that a packet superficially similar to an IPv4 packet
+   actually contained a different protocol, opening up the possibility
+   that an IPv4 node that simply ignored this option would process a
+   received packet in a manner inconsistent with the intent of the
+   sender.  There are no known threats arising from this option, other
+   than the general security implications of IP options discussed in
+   Section 3.
+
+4.16.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.16.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop packets that
+   contain this option.
+
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 24]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.17.  Address Extension (Type = 147)
+
+4.17.1.  Uses
+
+   The Address Extension option was introduced by one of the proposals
+   submitted during the IPng efforts to address the problem of IPv4
+   address exhaustion.
+
+4.17.2.  Option Specification
+
+   Specified in [RFC1475].  This option has been formally obsoleted by
+   [RFC6814].
+
+4.17.3.  Threats
+
+   There are no known threats arising from this option, other than the
+   general security implications of IP options discussed in Section 3.
+
+4.17.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.17.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop packets that
+   contain this option.
+
+4.18.  Sender Directed Multi-Destination Delivery (Type = 149)
+
+4.18.1.  Uses
+
+   This option originally provided unreliable UDP delivery to a set of
+   addresses included in the option.
+
+4.18.2.  Option Specification
+
+   This option is specified in RFC 1770 [RFC1770].  It has been formally
+   obsoleted by [RFC6814].
+
+4.18.3.  Threats
+
+   This option could have been exploited for bandwidth-amplification in
+   DoS attacks.
+
+4.18.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 25]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.18.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop IP packets that
+   contain a Sender Directed Multi-Destination Delivery option.
+
+4.19.  Dynamic Packet State (Type = 151)
+
+4.19.1.  Uses
+
+   The Dynamic Packet State option was used to specify the Dynamic
+   Packet State (DPS) in the context of the differentiated services
+   architecture.
+
+4.19.2.  Option Specification
+
+   The Dynamic Packet State option was specified in [DIFFSERV-DPS].  The
+   aforementioned document was meant to be published as "Experimental",
+   but never made it into an RFC.  This option has been formally
+   obsoleted by [RFC6814].
+
+4.19.3.  Threats
+
+   Possible threats include theft of service and denial of service.
+   However, we note that this option has never been widely implemented
+   or deployed.
+
+4.19.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.19.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop packets that
+   contain this option.
+
+4.20.  Upstream Multicast Pkt. (Type = 152)
+
+4.20.1.  Uses
+
+   This option was meant to solve the problem of doing upstream
+   forwarding of multicast packets on a multi-access LAN.
+
+4.20.2.  Option Specification
+
+   This option was originally specified in [BIDIR-TREES].  It was never
+   formally standardized in the RFC series and was never widely
+   implemented and deployed.  Its use was obsoleted by [RFC5015], which
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 26]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   employs a control-plane mechanism to solve the problem of doing
+   upstream forwarding of multicast packets on a multi-access LAN.  This
+   option has been formally obsoleted by [RFC6814].
+
+4.20.3.  Threats
+
+   This option is obsolete.  A router that ignored this option instead
+   of processing it as specified in [BIDIR-TREES] could have forwarded
+   multicast packets to an unintended destination.
+
+4.20.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.20.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD drop packets that
+   contain this option.
+
+4.21.  Quick-Start (Type = 25)
+
+4.21.1.  Uses
+
+   This IP Option is used in the specification of Quick-Start for TCP
+   and IP, which is an experimental mechanism that allows transport
+   protocols, in cooperation with routers, to determine an allowed
+   sending rate at the start and, at times, in the middle of a data
+   transfer (e.g., after an idle period) [RFC4782].
+
+4.21.2.  Option Specification
+
+   Specified in RFC 4782 [RFC4782], on the "Experimental" track.
+
+4.21.3.  Threats
+
+   Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
+   kinds of attacks:
+
+   o  attacks to increase the routers' processing and state load, and,
+
+   o  attacks with bogus Quick-Start Requests to temporarily tie up
+      available Quick-Start bandwidth, preventing routers from approving
+      Quick-Start Requests from other connections.
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 27]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.21.4.  Operational and Interoperability Impact if Blocked
+
+   The Quick-Start functionality would be disabled, and additional
+   delays in TCP's connection establishment (for example) could be
+   introduced.  (Please see Section 4.7.2 of [RFC4782].)  We note,
+   however, that Quick-Start has been proposed as a mechanism that could
+   be of use in controlled environments, and not as a mechanism that
+   would be intended or appropriate for ubiquitous deployment in the
+   global Internet [RFC4782].
+
+4.21.5.  Advice
+
+   A given router, security gateway, or firewall system has no way of
+   knowing a priori whether this option is valid in its operational
+   environment.  Therefore, routers, security gateways, and firewalls
+   SHOULD, by default, ignore the Quick-Start option.  Additionally,
+   routers, security gateways, and firewalls SHOULD have a configuration
+   setting that governs their reaction in the presence of packets
+   containing the Quick-Start option.  This configuration setting SHOULD
+   allow to honor and process the option, ignore the option, or drop
+   packets containing this option.  The default configuration is to
+   ignore the Quick-Start option.
+
+      We note that if routers in a given environment do not implement
+      and enable the Quick-Start mechanism, only the general security
+      implications of IP options (discussed in Section 3) would apply.
+
+4.22.  RFC3692-Style Experiment (Types = 30, 94, 158, and 222)
+
+   Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all
+   defined values of the "copy" and "class" fields for RFC3692-style
+   experiments.  This results in four distinct option type codes: 30,
+   94, 158, and 222.
+
+4.22.1.  Uses
+
+   It is only appropriate to use these values in explicitly configured
+   experiments; they MUST NOT be shipped as defaults in implementations.
+
+4.22.2.  Option Specification
+
+   Specified in RFC 4727 [RFC4727] in the context of RFC3692-style
+   experiments.
+
+4.22.3.  Threats
+
+   No specific security issues are known for this IPv4 option.
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 28]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+4.22.4.  Operational and Interoperability Impact if Blocked
+
+   None.
+
+4.22.5.  Advice
+
+   Routers, security gateways, and firewalls SHOULD have configuration
+   knobs for IP packets that contain RFC3692-style Experiment options to
+   select between "ignore & forward" and "drop & log".  Otherwise, no
+   legitimate experiment using these options will be able to traverse
+   any IP router.
+
+   Special care needs to be taken in the case of "drop & log".  Devices
+   SHOULD count the number of packets dropped, but the logging of drop
+   events SHOULD be limited so as to not overburden device resources.
+
+   The aforementioned configuration knob SHOULD default to "drop & log".
+
+4.23.  Other IP Options
+
+4.23.1.  Specification
+
+   Unrecognized IP options are to be ignored.  Section 3.2.1.8 of RFC
+   1122 [RFC1122] specifies this behavior as follows:
+
+      The IP and transport layer MUST each interpret those IP options
+      that they understand and silently ignore the others.
+
+   Additionally, Section 4.2.2.6 of RFC 1812 [RFC1812] specifies it as
+   follows:
+
+      A router MUST ignore IP options which it does not recognize.
+
+   This document adds that unrecognized IP options MAY also be logged.
+
+   Further, routers, security gateways, and firewalls MUST provide the
+   ability to log drop events of IP packets containing unrecognized or
+   obsolete options.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 29]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   A number of additional options are listed in the "IP OPTION NUMBERS"
+   IANA registry [IANA-IP] as of the time this document was last edited.
+   Specifically:
+
+   Copy Class Number Value Name
+   ---- ----- ------ ----- -------------------------------------------
+      0     0     10    10 ZSU    - Experimental Measurement
+      1     2     13   205 FINN   - Experimental Flow Control
+      0     0     15    15 ENCODE - ???
+      1     0     16   144 IMITD  - IMI Traffic Descriptor
+      1     0     22   150        - Unassigned (Released 18 Oct. 2005)
+
+   The ENCODE option (type 15) has been formally obsoleted by [RFC6814].
+
+4.23.2.  Threats
+
+   The lack of open specifications for these options makes it impossible
+   to evaluate their security implications.
+
+4.23.3.  Operational and Interoperability Impact if Blocked
+
+   The lack of open specifications for these options makes it impossible
+   to evaluate the operational and interoperability impact if packets
+   containing these options are blocked.
+
+4.23.4.  Advice
+
+   Routers, security gateways, and firewalls SHOULD have configuration
+   knobs for IP packets containing these options (or other options not
+   recognized) to select between "ignore & forward" and "drop & log".
+
+   Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that
+   unrecognized IP options MUST be ignored.  However, the previous
+   paragraph states that routers, security gateways, and firewalls
+   SHOULD have a configuration option for dropping and logging IP
+   packets containing unrecognized options.  While it is acknowledged
+   that this advice contradicts the previous RFCs' requirements, the
+   advice in this document reflects current operational reality.
+
+   Special care needs to be taken in the case of "drop & log".  Devices
+   SHOULD count the number of packets dropped, but the logging of drop
+   events SHOULD be limited so as to not overburden device resources.
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 30]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+5.  Security Considerations
+
+   This document provides advice on the filtering of IP packets that
+   contain IP options.  Dropping such packets can help to mitigate the
+   security issues that arise from use of different IP options.  Many of
+   the IPv4 options listed in this document are deprecated and cause no
+   operational impact if dropped.  However, dropping packets containing
+   IPv4 options that are in use can cause real operational problems in
+   deployed networks.  Therefore, the practice of dropping all IPv4
+   packets containing one or more IPv4 options without careful
+   consideration is not recommended.
+
+6.  Acknowledgements
+
+   The authors would like to thank (in alphabetical order) Ron Bonica,
+   C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo
+   Servin, SM, and Donald Smith for providing thorough reviews and
+   valuable comments.  Merike Kaeo also contributed text used in this
+   document.
+
+   The authors also wish to thank various network operations folks who
+   supplied feedback on earlier versions of this document but did not
+   wish to be named explicitly in this document.
+
+   Part of this document is initially based on the document "Security
+   Assessment of the Internet Protocol" [CPNI2008] that is the result of
+   a project carried out by Fernando Gont on behalf of UK CPNI (formerly
+   NISCC).  Fernando Gont would like to thank UK CPNI (formerly NISCC)
+   for their continued support.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+              November 1990.
+
+   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
+              1812, June 1995.
+
+   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113, February
+              1997.
+
+
+
+Gont, et al.              Best Current Practice                [Page 31]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
+              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, March 2007.
+
+   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+              "Bidirectional Protocol Independent Multicast (BIDIR-
+              PIM)", RFC 5015, October 2007.
+
+   [RFC6398]  Le Faucheur, F., "IP Router Alert Considerations and
+              Usage", BCP 168, RFC 6398, October 2011.
+
+   [RFC6814]  Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
+              Options", RFC 6814, November 2012.
+
+7.2.  Informative References
+
+   [BIDIR-TREES]
+              Estrin, D. and D. Farinacci, "Bi-Directional Shared Trees
+              in PIM-SM", Work in Progress, May 1999.
+
+   [BREMIER-BARR]
+              Bremier-Barr, A. and H. Levy, "Spoofing prevention
+              method", Proceedings of IEEE InfoCom 2005, Volume 1, pp.
+              536-547, March 2005.
+
+   [Biondi2007]
+              Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
+              CanSecWest 2007 Security Conference, 2007,
+              <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
+
+   [CIPSOWG1994]
+              IETF CIPSO Working Group, "Commercial Internet Protocol
+              Security Option (CIPSO) Charter", 1994,
+              <http://www.ietf.org/proceedings/94jul/charters/
+              cipso-charter.html>.
+
+   [CIPSO]    IETF CIPSO Working Group, "COMMERCIAL IP SECURITY OPTION
+              (CIPSO 2.2)", Work in Progress, 1992.
+
+   [CPNI2008] Gont, F., "Security Assessment of the Internet Protocol",
+              2008,
+              <http://www.gont.com.ar/papers/InternetProtocol.pdf>.
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 32]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   [Cisco-IPSO-Cmds]
+              Cisco Systems, Inc., "IP Security Options Commands", Cisco
+              IOS Security Command Reference, Release 12.2,
+              <http://www.cisco.com/en/US/docs/ios/12_2/security/
+              command/reference/srfipso.html>.
+
+   [Cisco-IPSO]
+              Cisco Systems, Inc., "Configuring IP Security Options",
+              Cisco IOS Security Configuration Guide, Release 12.2,
+              2006, <http://www.cisco.com/en/US/docs/ios/12_2/security/
+              configuration/guide/scfipso.html>.
+
+   [DIFFSERV-DPS]
+              Stoica, I., Zhang, H., Venkitaram, N., and J. Mysore, "Per
+              Hop Behaviors Based on Dynamic Packet State", Work in
+              Progress, October 2002.
+
+   [FIPS1994]
+              FIPS, "Standard Security Label for Information Transfer",
+              Federal Information Processing Standards Publication, FIP
+              PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/
+              fips188/fips188.pdf>.
+
+   [FONSECA]  Fonseca, R., Porter, G., Katz, R., Shenker, S., and I.
+              Stoica, "IP Options are not an option", EECS Department,
+              University of California, Berkeley, December 2005,
+              <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/
+              EECS-2005-24.html>.
+
+   [IANA-IP]  IANA, "IP OPTION NUMBERS",
+              <http://www.iana.org/assignments/ip-parameters>.
+
+   [IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008,
+              <http://techpubs.sgi.com/library/tpl/cgi-bin/
+              getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/
+              cat7/trusted_networking.z>.
+
+   [Kohno2005]
+              Kohno, T., Broido, A., and kc. Claffy, "Remote Physical
+              Device Fingerprinting", IEEE Transactions on Dependable
+              and Secure Computing, Vol. 2, No. 2, 2005.
+
+   [Landwehr81]
+              Landwehr, C., "Formal Models for Computer Security", ACM
+              Computing Surveys, Vol. 13, No. 3, Association for
+              Computing Machinery, New York, NY, USA, September 1981.
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 33]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   [MEDINA]   Medina, A., Allman, M., and S. Floyd, "Measuring
+              Interactions Between Transport Protocols and Middleboxes",
+              Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
+              Measurement, October 2004.
+
+   [Microsoft1999]
+              Microsoft, "Microsoft Security Program: Microsoft Security
+              Bulletin (MS99-038). Patch Available for "Spoofed Route
+              Pointer" Vulnerability", September 1999,
+              <http://www.microsoft.com/technet/security/bulletin/
+              ms99-038.mspx>.
+
+   [OpenBSD1998]
+              OpenBSD, "OpenBSD Security Advisory: IP Source Routing
+              Problem", February 1998,
+              <http://www.openbsd.org/advisories/sourceroute.txt>.
+
+   [RFC1038]  St. Johns, M., "Draft revised IP security option", RFC
+              1038, January 1988.
+
+   [RFC1063]  Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
+              MTU discovery options", RFC 1063, July 1988.
+
+   [RFC1108]  Kent, S., "U.S. Department of Defense Security Options for
+              the Internet Protocol", RFC 1108, November 1991.
+
+   [RFC1385]  Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
+              November 1992.
+
+   [RFC1393]  Malkin, G., "Traceroute Using an IP Option", RFC 1393,
+              January 1993.
+
+   [RFC1475]  Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June
+              1993.
+
+   [RFC1770]  Graff, C., "IPv4 Option for Sender Directed Multi-
+              Destination Delivery", RFC 1770, March 1995.
+
+   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC2407]  Piper, D., "The Internet IP Security Domain of
+              Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RFC3585]  Jason, J., Rafalow, L., and E. Vyncke, "IPsec
+              Configuration Policy Information Model", RFC 3585, August
+              2003.
+
+
+
+Gont, et al.              Best Current Practice                [Page 34]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+              4306, December 2005.
+
+   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
+              Start for TCP and IP", RFC 4782, January 2007.
+
+   [RFC4807]  Baer, M., Charlet, R., Hardaker, W., Story, R., and C.
+              Wang, "IPsec Security Policy Database Configuration MIB",
+              RFC 4807, March 2007.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
+              4949, August 2007.
+
+   [RFC5350]  Manner, J. and A. McDonald, "IANA Considerations for the
+              IPv4 and IPv6 Router Alert Options", RFC 5350, September
+              2008.
+
+   [RFC5570]  StJohns, M., Atkinson, R., and G. Thomas, "Common
+              Architecture Label IPv6 Security Option (CALIPSO)", RFC
+              5570, July 2009.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
+              5996, September 2010.
+
+   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
+              Router Control Plane", RFC 6192, March 2011.
+
+   [RFC6274]  Gont, F., "Security Assessment of the Internet Protocol
+              Version 4", RFC 6274, July 2011.
+
+   [SELinux2008]
+              National Security Agency (United States), "Security-
+              Enhanced Linux - NSA/CSS", January 2009,
+              <http://www.nsa.gov/research/selinux/index.shtml>.
+
+   [Solaris2008]
+              "Solaris Trusted Extensions: Labeled Security for Absolute
+              Protection", 2008,
+              <http://www.oracle.com/technetwork/server-storage/
+              solaris10/overview/trusted-extensions-149944.pdf>.
+
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 35]
+
+RFC 7126            Filtering of IP-Optioned Packets       February 2014
+
+
+Authors' Addresses
+
+   Fernando Gont
+   UTN-FRH / SI6 Networks
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   EMail: fgont@si6networks.com
+   URI:   http://www.si6networks.com
+
+
+   RJ Atkinson
+   Consultant
+   McLean, VA  22103
+   USA
+
+   EMail: rja.lists@gmail.com
+
+
+   Carlos Pignataro
+   Cisco Systems, Inc.
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   USA
+
+   EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont, et al.              Best Current Practice                [Page 36]
+