Message-ID: <CALx6S369Cb-9mtD3hSS0udTHZ_4r5d+2UD8zfsonjfM7QrHhAA@mail.gmail.com>
Date: Fri, 21 Nov 2025 13:23:22 -0800
From: Tom Herbert <tom@...bertland.com>
To: Justin Iurman <justin.iurman@...ege.be>
Cc: davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org
Subject: Re: [RFC net-next 2/3] ipv6: Disable IPv6 Destination Options RX
 processing by default

On Thu, Nov 13, 2025 at 5:17 AM Justin Iurman <justin.iurman@...ege.be> wrote:
>
> 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...

Hi Justin,

It's a nice idea, but given the turnaround times for the IETF process
it would take years. Also to implement that in the stack isn't
particularly trivial. Avoiding the potential DoS attack is the higher
priority problem IMO, and disabling DestOpts by default will have
little impact since almost no one is using them..

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

Sure, but  where is the Linux implementation? Deployment?
>
> > * 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...

The drop rates for Destination Options vary by size of the extension
header. AP NIC data shows that 32 bytes options have about a 30% drop
rate, 64 byte options have about a 40% drop rate, but 128 byte options
have over 80% drop rate. The drops are coming from routers and not
hosts, Linux has no problem with different sizes. As you know from the
6man list discussions, I proposed a minimum level of support that
routers must forward packets with up to 64 bytes of extension headers,
but that draft was rejected because of concerns that it would ossify
an already ossified protocol :-(. Even if a 40% drop rate isn't "that
bad" the 80% drop rate of 128 bytes EH would seem to qualify as "bad".
In any case, no one in IETF has offered an alternative plan to address
the high loss rates and without a solution I believe it's fair to say
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 thenthatit
> >    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).

I considered that, but there is a problem in that when we process HBH
options we don't know if we're a host (i.e. the final destination) or
a router (i.e. the packet will be forwarded). I would prefer to keep
it simple and drop whenever a limit is exceeded. RFC9673 does allow a
host to skip over HBH options, but IMO it's too risky to blindly
accept a packet without verifying all the headers.

Tom

Powered by blists - more mailing lists