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] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Dec 2023 09:33:39 -0700
From: Dan Moulding <dan@...m.net>
To: alexhenrie24@...il.com
Cc: bagasdotme@...il.com,
	dan@...m.net,
	davem@...emloft.net,
	dsahern@...nel.org,
	edumazet@...gle.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	regressions@...ts.linux.dev
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail

I think a maintainer will probably need to make a call here and decide
how to proceed.

> TEMP_PREFERRED_LIFETIME is an administratively set variable: The user
> can change it to whatever they want whenever they want, and the
> operating system can adjust it automatically too.

Agreed. And the behavior it seems you really want is to prevent the
user from administratively setting it to a value that is lower than
REGEN_ADVANCE, so that it won't stop generating new temporary
addresses altogether.

But preventing the user from configuring it to a value that is too low
is different from generating new temporary addresses with preferred
lifetimes that are greater than the currently configured value of
TEMP_PREFERRED_LIFETIME. I still believe it would be better, and would
be in conformance with the RFC, to simply not allow the user to
configure a too-short TEMP_PREFERRED_LIFETIME instead of tinkering
with the lifetimes of generated temporary addresses.

> It's fine to revert the commit for version 6.7 (after all, I think
> everyone wants a break for the holidays). Hopefully by version 6.8 we
> can agree on a way to support users who want to randomize their IPv6
> address as frequently as the network allows.

FWIW, I think the desired effect you are seeking makes sense and is
the right thing to do. I'm just not convinced this is the correct way
to do it. But I'm not a maintainer and also not an expert in IPv6, so
I'm definitely not the right person to make that call.

-- Dan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ