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] [day] [month] [year] [list]
Message-ID: <CAK-6q+jm51Co0k6cR0fMDXxJiM2G8z_nF8LjrcdCcSnGrap8EA@mail.gmail.com>
Date: Tue, 16 Jul 2024 17:27:00 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Mathis Marion <mathis.marion@...abs.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, alex.aring@...il.com, davem@...emloft.net, 
	dsahern@...nel.org, edumazet@...gle.com, jerome.pouiller@...abs.com, 
	kuba@...nel.org, kylian.balan@...abs.com, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org, pabeni@...hat.com, 
	Michael Richardson <mcr@...delman.ca>
Subject: Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0
 segments left

Hi,

On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@...abs.com> wrote:
>
> On 26/06/2024 3:45 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@...abs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@...abs.com>
> >>>
> >>> Routing headers of type 3 and 4 would be rejected even if segments left
> >>> was 0, in the case that they were disabled through system configuration.
> >>>
> >>> RFC 8200 section 4.4 specifies:
> >>>
> >>>        If Segments Left is zero, the node must ignore the Routing header
> >>>        and proceed to process the next header in the packet, whose type
> >>>        is identified by the Next Header field in the Routing header.
> >>
> >> I think this part is only applied to an unrecognized Routing Type,
> >> so only applied when the network stack does not know the type.
> >>
> >>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
> >>
> >>     If, while processing a received packet, a node encounters a Routing
> >>     header with an unrecognized Routing Type value, the required behavior
> >>     of the node depends on the value of the Segments Left field, as
> >>     follows:
> >>
> >>        If Segments Left is zero, the node must ignore the Routing header
> >>        and proceed to process the next header in the packet, whose type
> >>        is identified by the Next Header field in the Routing header.
> >>
> >> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
> >>
> >> But now the kernel recognizes RPL and it's intentionally disabled
> >> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
> >>
> >> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> >
> > so there might be a need to have an opt-in knob to actually tell the
> > kernel ipv6 stack to recognize or not recognize a next header field
> > for users wanting to bypass certain next header fields to the user
> > space?
> >
> > - Alex
> >
>
> My point is that if a particular routing header support is disabled
> through system configuration, it should be treated as any unrecognized
> header. From my perspective, doing otherwise causes a regression every
> time a new routing header is supported.
>

coming back to this. I think you need to add another switch to do that
and turn it by default in whatever the current default situation is,
otherwise this patch will break the next person's behaviour.

- Alex


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ