netdev - Re: [RFC net-next 0/3] ipv6: Disable IPv6 Destination Options RX processing by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46a0fab0-e904-4745-a0df-28cfb8a00bee@uliege.be>
Date: Thu, 13 Nov 2025 14:18:35 +0100
From: Justin Iurman <justin.iurman@...ege.be>
To: Tom Herbert <tom@...bertland.com>, davem@...emloft.net, kuba@...nel.org,
 netdev@...r.kernel.org
Cc: justin.iurman@...ege.be
Subject: Re: [RFC net-next 0/3] ipv6: Disable IPv6 Destination Options RX
 processing by default

On 11/12/25 01:15, Tom Herbert wrote:
> Set IP6_DEFAULT_MAX_DST_OPTS_CNT to zero. This disables
> processing of Destinations Options extension headers by default.
> Processing can be enabled by setting the net.ipv6.max_dst_opts_number
> to a non-zero value.
> 
> The rationale for this is that Destination Options pose a serious risk
> of Denial off Service attack. The problem is that even if the
> default limit is set to a small number (previously it was eight) there
> is still the possibility of a DoS attack. 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 it is
> a lot of work and CPU cycles that provide 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
> 
> Tom Herbert (3):
> 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: Document defauit of zero for max_dst_opts_number
> 
>   Documentation/networking/ip-sysctl.rst | 38 ++++++++++++++++++--------
>   include/net/ipv6.h                     |  7 +++--
>   net/ipv6/exthdrs.c                     |  6 ++--
>   3 files changed, 36 insertions(+), 15 deletions(-)
> 

Adding the two IETF 6man related threads ([1,2]) to bring context and to 
highlight what has been discussed so far.

  [1] 
https://mailarchive.ietf.org/arch/msg/ipv6/J_9vPNzyllNAudXwJdqdHwgzT8A/
  [2] 
https://mailarchive.ietf.org/arch/msg/ipv6/jMTQJz5bAVmLyBhtgh-pmJR3MMM/