Message-ID: <willemdebruijn.kernel.b21ec5446983@gmail.com>
Date: Sat, 31 Jan 2026 12:24:26 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Tom Herbert <tom@...bertland.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Justin Iurman <justin.iurman@...il.com>, 
 davem@...emloft.net, 
 kuba@...nel.org, 
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering

Tom Herbert wrote:
> On Thu, Jan 29, 2026 at 11:05 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > Justin Iurman wrote:
> > > On 1/29/26 06:18, Willem de Bruijn wrote:
> > > > Tom Herbert wrote:
> > > >> RFC8200 highly recommends that different Extension Headers be send in
> > > >> a prescibed order and all Extension Header types occur at most once
> > > >> in a packet with the exception of Destination Options that may
> > > >> occur twice. This patch enforces the ordering be folowed in received
> > > >> packets.
> > > >>
> > > >> The allowed order of Extension Headers is:
> > > >>
> > > >>      IPv6 header
> > > >>      Hop-by-Hop Options header
> > > >>      Destination Options before the Routing Header
> > > >>      Routing header
> > > >>      Fragment header
> > > >>      Authentication header
> > > >>      Encapsulating Security Payload header
> > > >>      Destination Options header
> > > >>      Upper-Layer header
> > > >>
> > > >> Each Extension Header may be present only once in a packet.
> > > >>
> > > >> net.ipv6.enforce_ext_hdr_order is a sysctl to enable or disable
> > > >> enforcement of xtension Header order. If it is set to zero then
> > > >
> > > > [e]xtension. There are a few more typos in the various commit
> > > > messages.
> > > >
> > > >> Extension Header order and number of occurences is not checked
> > > >> in receive processeing (except for Hop-by-Hop Options that
> > > >> must be the first Extension Header and can only occur once in
> > > >> a packet.
> > > >
> > > > RFC 8200 also states
> > > >
> > > >     "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."
> > > >
> > > > A case of be strict in what you send, liberal in what you accept.
> > > >
> > > > This new sysctl has a chance of breaking existing users.
> > >
> > > Willem,
> > >
> > > Note that RFC8200 does not use normative language, which is part of the
> > > problem. It could theoretically break existing users, but I don't think
> > > it will in reality. For that, you would need users to beginning with
> > > (joke aside, I like EHs). Anyway, if the order is enforced at sending,
> > > why would any receiver accept a different order? In this case, being
> > > liberal in what we accept might be a security risk (see below).
> > >
> > > > The series as a whole is framed as a security improvement. Does
> > > > enforcing order help with that?
> > >
> > > IMHO, any packet with EHs in a different order than the one specified in
> > > RFC8200 looks suspicious. So, yes.
> >
> 
> Hi Willem, thanks for your comments!
> 
> > Looks suspicious. But does not introduce concrete new risks?
> 
> Hard to say specifically. On the other hand, there's no known use
> cases for alternatives for it and given all the other security perils
> a strong default security posture wrt EH order seems prudent.
> 
> >
> > The main risk I understand around IPv6 extension headers is the risk
> > common to all untrusted network input: bugs in parsing code. Bugs can
> > cause crashes, infinite loops, or worse subtle effects. This is why we
> > introduced the BPF flow dissector, for instance.
> 
> I believe the main risk is Denial of Service attacks and security
> vulnerabilities.
> 
> >
> > I don't immediately see how different order of headers increases
> > parsing risk. Nor, btw, that reducing max number of headers from 8 to
> > 2 significantly mitigates a real risk.
> 
> It's a similar rationale to putting a limit on the number of options
> in the first place. Going from 700 options allowed in a packet to at
> most 8 allowed was a no brainer. But even 8 is too much considering
> that the stack only supports three Hop-by-Hop options and two
> Destination options. There's a common misnomer that only hardware has
> trouble parsing TLVs, and somehow it's free in SW (I've been battling
> that mindset!). For instance, a well constructed attack could force
> one cache, maybe two cache misses per each option. So going from 8 to
> 2 as the default limit could materially mitigate the damage for a DoS
> attack on options.
> 
> >
> > No objections necessarily. But I don't fully understand the argument.
> 
> We selected the default value of eight in RFC8504 based on an
> expectation that there might be new options defined and that the
> Internet would be fixed to reliably support extension headers
> including those with options. I do not believe either of those are
> going to happen.
> 
> Hop-by-Hop Options are ostensibly the right way to do network to host
> and host to network signaling.The only HBH options that might get any
> substantial deployment are Router Alert option and IOAM. The Router
> Alert option is being deprecated and IOAM is at best a "nice toi
> have". The best use case of Hop-by-Hop options is congestion
> signaling, unfortunately the die was cast when CSIG authors decided to
> place the information in VLANs at L2 and cajole the information to be
> routable through a switch. IMO, the miss on CSIG pretty much is the
> nail in the coffin for Hop-by-Hop options to ever be widely deployed
> (https://www.ietf.org/archive/id/draft-ravi-ippm-csig-01.txt).
> 
> Destination Options have proven even less useful than Hop-by-Hop
> Options. The only Destination Option supported by the stack is the
> Tunnel Encap Limit option and Home Address Options. The Tunnel Encap
> Option was buried in the v6 tunnel code which is why it wasn't obvious
> it was supported in the first version of the patch set.  I'll assume
> this might be useful, so this patch set cleans up the code for it. I
> don't believe there's any use of Home Address Option.
> 
> A major problem with DestOpts, HBH, Routing Header, and Fragment
> header is that they have no inherent security. Their use presents a
> security risk especially when sent over untrusted networks including
> the Internet. Given that and that the high drop rates of extension
> headers on the Internet, I am proposing that Extension header except
> fo ESP being deprecated on the Internet
> (https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-01.txt).
> 
> IMO, IPv6 Extension Headers are a failed experiment in protocol
> design. The vast majority of hosts do not care about them, and the
> best use case for them is Denial of Service attack. So IMO the greater
> good is to limit them as much as possible. If some private network
> finds a use case for them they can also configure sysctls if they
> don't like the default behavior.

Thanks for the detailed context, Tom. May be good to fold into the
cover letter or commit message if respinning.

One remaining question: these features may be largely unused by
Linux systems, and Linux peers can be expected to follow RFC
directives on ordering.

But may there be other peers in the wild that are not necessarily
malicious, but just less strict. IOW could this break legitimate
users in the long tail of use cases of Linux in the wild?
Probably good to explicitly state if we are not aware of any.

Or abuses of extension headers for private reasons inside non-public
networks.

The risk/reward of lowering from 8 to 2 to me offers at best a small
real increase in security, but it may have real regression risk in odd
installations?

Powered by blists - more mailing lists