netdev - Re: IPv6 Router Advertisement Router Preference (RFC 4191) behavior issue

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]

Date:   Fri, 3 Dec 2021 09:39:26 +0200
From:   Juhamatti Kuusisaari <juhamatk@...il.com>
To:     Jeroen Massar <jeroen@...sar.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: IPv6 Router Advertisement Router Preference (RFC 4191) behavior issue

Hello,

On Thu, 18 Nov 2021 at 15:12, Juhamatti Kuusisaari <juhamatk@...il.com> wrote:
>
> On Thu, 18 Nov 2021 at 12:49, Jeroen Massar <jeroen@...sar.ch> wrote:
> >
> >
> >
> > > On 20211118, at 11:35, Juhamatti Kuusisaari <juhamatk@...il.com> wrote:
> > >
> > > Hello,
> > >
> > > I have been testing IPv6 Router Advertisement Default Router
> > > Preference on 5.1X and it seems it is not honoured by the Linux
> > > networking stack. Whenever a new default router preference with a
> > > higher or lower preference value is received, a new default gateway is
> > > added as an ECMP route in the routing table with equal weight. This is
> > > a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
> > > preference value should be preferred. This part seems to be missing
> > > from the Linux implementation.
> >
> > Do watch out that there are a couple of user space tools (yes, that thing) that think that they have to handle RAs.... and thus one might get conflicts about reasoning between the kernel doing it or that user space daemon thing.
>
> Thanks for the heads-up. AFAIK, I am not running anything extra in the
> user space of the receiving node.
>
> Here are some more details:
>
> 1) RA with pref medium is received over enp0s8 from router X at
> fe80::a00:27ff:fe90:5a8a:
> ::1 dev lo proto kernel metric 256 pref medium
> fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
> fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
> default via fe80::a00:27ff:fe90:5a8a dev enp0s8 proto ra metric 1024
> expires 273sec pref medium
>
> 2) RA with pref high is received over enp0s8 from router Y at
> fe80::ffff:a00:275e:85ca:
> ::1 dev lo proto kernel metric 256 pref medium
> fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
> fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
> default proto ra metric 1024 expires 276sec pref medium
>         nexthop via fe80::a00:27ff:fe90:5a8a dev enp0s8 weight 1
>         nexthop via fe80::ffff:a00:275e:85ca dev enp0s8 weight 1
>
> i.e. the default ends up as an ECMP configuration. I would have
> expected it to change to a high preference route via
> fe80::ffff:a00:275e:85ca only.

The above behaviour does not quite match the code - and indeed, a
userspace tool did take over RAs by default. I disabled it and the
kernel behaviour looks like this:

::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::a00:27ff:fe5e:85ca dev enp0s8 proto ra metric 1024
expires 261sec pref medium
default via fe80::ffff:a00:275e:85ca dev enp0s8 proto ra metric 1024
expires 261sec pref high

To be sure, I verified from ND-kernel logs that this really goes to the kernel.

It still does not look quite right to me. I would have expected, based
on the RFC 4191, that only high pref default is there or that it has
priority by other means. AFAICT, now the routing takes the default
that happens to match the lookup first. Without router preference this
is fine.

Thanks,
--
 Juhamatti