[PATCH net-next v2 0/4] ipv6: Disable IPv6 Destination Options RX processing by default

[Tom Herbert <tom@herbertland.com>]

This patchset set changes the interpretation of the Destination Options
and Hop-by-Hop Options sysctl limits, net.ipv6.max_dst_opts_number and
net.ipv6.max_dst_opts_number to mean that when the sysctl is zero
processing of the associated extension header is disabled such that
packets received with the extension header are dropped.

This patch sets the default limit for Destination Options to zero
meaning that packets with Destination Options are dropped by default.
The rationale for this is that Destinations Options extension header
can be used in an effective Denial of Service attack, and Destination
Options have very little or possibly no deployment. Note that the only
non-padding Destination option supported by the kernel is the Home
Address Option (RFC6275). It is unknown if anyone is using that.

The Denial of Service attack goes like this: All an attacker needs to
do is create and MTU size packet filled  with 8 bytes Destination
Options Extension Headers. Each Destination EH simply contains a single
padding option with six bytes of zeroes. In a 1500 byte MTU size
packet, 182 of these dummy Destination Options headers can be placed
in a packet. Per RFC8200, a host must accept and process a packet with
any number of Destination Options extension headers. So when the stack
processes such a packet is a lot of work and CPU cycles that yield zero
benefit. The packet can be designed such that every byte after the IP
header requires a conditional check and branch prediction can be
rendered useless for that. This also may mean over twenty cache misses
per packet. In other words, these packets filled with dummy Destination
Options extension headers are the basis for what would be an effective
DoS attack.

Disabling Destination Options is not a major issue for the following
reasons:

* Linux kernel only supports one Destination Option (Home Address
  Option). There is no evidence this has seen any real world use

* On the Internet packets with Destination Options are dropped with
  a high enough rate such that use of Destination Options is not
  feasible

* It is unknown however quite possible that no one anywhere is using
  Destination Options for anything but experiments, class projects,
  or DoS. If someone is using them in their private network then
  it's easy enough to configure a non-zero limit for their use case

Additionally, this patch set sets the default limit of number of
Hop-by-Hop options to one. The rationale is similar to disabling
Destination options on RX however unlike Destination options
Hop-by-Hop options have one common use case in the Router
Alert option. It should be noted that RFC9673, IPv6 Hop-by-Hop
Options Processing Procedures, states "A Source MAY, based on local
configuration, allow only one Hop-by-Hop option to be included in a
packet". That implies an expectation that one Hop-by-Hop may be
suffcient.

Note that the limits on number of non-padding Destination options and
the number of Hop-by-Hop options are configurable via a sysctl.

Tom Herbert (4):
  ipv6: Check of max HBH or DestOp sysctl is zero and drop if it is
  ipv6: Disable IPv6 Destination Options RX processing by default
  ipv6: Set Hop-by-Hop options limit to 1
  ipv6: Document defaults for max_{dst|hbh}_opts_number sysctls

 Documentation/networking/ip-sysctl.rst | 38 ++++++++++++++++++--------
 include/net/ipv6.h                     |  9 ++++--
 net/ipv6/exthdrs.c                     |  6 ++--
 3 files changed, 37 insertions(+), 16 deletions(-)

-- 
2.43.0