netdev - RE: iproute2 ECMP should display expiry for each nexthop

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: <SJ0PR84MB20889CA976BE6C8DFD2C864FD8DF2@SJ0PR84MB2088.NAMPRD84.PROD.OUTLOOK.COM>
Date: Fri, 5 Jul 2024 04:33:35 +0000
From: "Muggeridge, Matt" <matt.muggeridge2@....com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: iproute2 ECMP should display expiry for each nexthop

> From: Muggeridge, Matt
> Sent: Friday, July 5, 2024 9:51 AM
> To: netdev@...r.kernel.org
> Subject: iproute2 ECMP should display expiry for each nexthop
> 
> The output from iproute2 is misleading. It shows an expiry time in the header
> of the nexthop list, which suggests all nexthops are goverened by the same
> expiry time. However, my testing proves that is not the case. Each nexthop
> expires according to its own expiration.
> 
> E.g. imagine a host receives an RA with lifetime=10s from TR1. Then 5 seconds
> later, it receives an RA with lifetime=10s from TR2. iproute2 displays them as:
> 
> 
> $ ip -6 route
> default proto ra metric 2048 expires 6sec pref medium
>         nexthop via fe80::200:10ff:fe10:1061 dev enp0s9 weight 1
>         nexthop via fe80::200:10ff:fe10:1060 dev enp0s9 weight 1
> 
> 
> From the output, you would be forgiven for thinking that both nexthops will
> expire in 6 seconds. However, they expire according to their own lifetimes.
> In this example, TR2 expires 5s after TR1, since that's when they were received.
> 
> FWIW, my Ubuntu 24.04 system uses networkd, which configures routes via
> NetLink.
> 
> Matt.

After reading through the iproute2 source and kernel source that processes the
RTM_GETROUTE ip6_fib.c:inet6_dump_fib(), it seems the kernel does not store an
expiry timer with the nexthop. So now, I'm thinking networkd must be managing
the timers for each nexthop. I'll turn my attention back toward it.