netdev - Re: [PATCH v2 net-next] ipv6: Implement draft-ietf-6man-rfc4941bis

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, 1 May 2020 00:54:09 -0300
From:   Fernando Gont <fgont@...networks.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next] ipv6: Implement draft-ietf-6man-rfc4941bis

On 1/5/20 00:23, David Miller wrote:
> From: Fernando Gont <fgont@...networks.com>
> Date: Sun, 26 Apr 2020 12:41:40 -0300
> 
>> Implement the upcoming rev of RFC4941 (IPv6 temporary addresses):
>> https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-09
>>
>> * Reduces the default Valid Lifetime to 2 days
>>    The number of extra addresses employed when Valid Lifetime was
>>    7 days exacerbated the stress caused on network
>>    elements/devices. Additionally, the motivation for temporary
>>    addresses is indeed privacy and reduced exposure. With a
>>    default Valid Lifetime of 7 days, an address that becomes
>>    revealed by active communication is reachable and exposed for
>>    one whole week. The only use case for a Valid Lifetime of 7
>>    days could be some application that is expecting to have long
>>    lived connections. But if you want to have a long lived
>>    connections, you shouldn't be using a temporary address in the
>>    first place. Additionally, in the era of mobile devices, general
>>    applications should nevertheless be prepared and robust to
>>    address changes (e.g. nodes swap wifi <-> 4G, etc.)
>>
>> * Employs different IIDs for different prefixes
>>    To avoid network activity correlation among addresses configured
>>    for different prefixes
>>
>> * Uses a simpler algorithm for IID generation
>>    No need to store "history" anywhere
>>
>> Signed-off-by: Fernando Gont <fgont@...networks.com>
> 
> Please respin this patch as it no longer applies cleanly.  It should
> be easy, it's just because of the ReST conversion of ip-sysctl.txt

Just did, as [PATCH v3 net-next]. No code changes. Just rebased the 
patch on origin/master.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@...networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492