Message-ID: <d7793ec7-7d34-4a46-8f17-c4ff1152e232@uliege.be>
Date: Thu, 13 Nov 2025 14:17:53 +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 2/3] ipv6: Disable IPv6 Destination Options RX
 processing by default

On 11/12/25 01:16, Tom Herbert wrote:
> Set IP6_DEFAULT_MAX_HBH_OPTS_CNT to zero. This disables

s/IP6_DEFAULT_MAX_HBH_OPTS_CNT/IP6_DEFAULT_MAX_DST_OPTS_CNT

> 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.

How about a new document to update RFC8200 Sec. 4.1.? Maybe we can get 
6man consensus to enforce only one occurrence (vs. 2 for the Dest) for 
each extension header. Let alone the recommended order (without 
normative language), we could...

OLD:
    Each extension header should occur at most once, except for the
    Destination Options header, which should occur at most twice (once
    before a Routing header and once before the upper-layer header).

NEW:
    Each extension header MUST occur at most once, except for the
    Destination Options header, which MUST occur at most twice (once
    before a Routing header and once before the upper-layer header).

...and...

OLD:
    IPv6 nodes must accept and attempt to process extension headers in
    any order and occurring any number of times in the same packet,
    except for the Hop-by-Hop Options header, which is restricted to
    appear immediately after an IPv6 header only.  Nonetheless, it is
    strongly advised that sources of IPv6 packets adhere to the above
    recommended order until and unless subsequent specifications revise
    that recommendation.

NEW:
    IPv6 nodes must accept and attempt to process extension headers in
    any order in the same packet,
    except for the Hop-by-Hop Options header, which is restricted to
    appear immediately after an IPv6 header only.  Nonetheless, it is
    strongly advised that sources of IPv6 packets adhere to the above
    recommended order until and unless subsequent specifications revise
    that recommendation.

> 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

IMO, this is precisely the one designed for such real world end-to-end 
use cases (e.g., PDM [RFC8250] and PDMv2 [draft-ietf-ippm-encrypted-pdmv2]).

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

I wouldn't say that a 10-20% drop is *that* bad (i.e., "not feasible") 
for sizes < 64 bytes. But anyway...

> * 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
> ---
>   include/net/ipv6.h | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 74fbf1ad8065..723a254c0b90 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -86,8 +86,11 @@ struct ip_tunnel_info;
>    * silently discarded.
>    */
>   
> -/* Default limits for Hop-by-Hop and Destination options */
> -#define IP6_DEFAULT_MAX_DST_OPTS_CNT	 8
> +/* Default limits for Hop-by-Hop and Destination options. By default
> + * packets received with Destination Options headers are dropped to thwart
> + * Denial of Service attacks (see sysctl documention)
> + */
> +#define IP6_DEFAULT_MAX_DST_OPTS_CNT	 0
>   #define IP6_DEFAULT_MAX_HBH_OPTS_CNT	 8
>   #define IP6_DEFAULT_MAX_DST_OPTS_LEN	 INT_MAX /* No limit */
>   #define IP6_DEFAULT_MAX_HBH_OPTS_LEN	 INT_MAX /* No limit */

I'd rather prefer to update RFC8200 and enforce a maximum of 2 
occurrences for the Dest, and keep the default limit of 8 options.

Also, regardless of what we do here (and this remark also applies to the 
Hop-by-Hop), I think it's reasonable for a *host* to drop packets with a 
number of Hbh or Dest options that exceeds the configured limit. 
However, for a router (i.e., forwarding mode), I'd prefer to skip the EH 
chain rather than drop packets (for obvious reasons).

Powered by blists - more mailing lists