netdev - Re: [PATCH 2/2] IPv6: fix DESYNC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20161014.105940.1675318884308466691.davem@davemloft.net>
Date:   Fri, 14 Oct 2016 10:59:40 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     jbohac@...e.cz
Cc:     kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
        kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] IPv6: fix DESYNC_FACTOR

From: Jiri Bohac <jbohac@...e.cz>
Date: Thu, 13 Oct 2016 18:52:15 +0200

> The IPv6 temporary address generation uses a variable called DESYNC_FACTOR
> to prevent hosts updating the addresses at the same time. Quoting RFC 4941:
> 
>    ... The value DESYNC_FACTOR is a random value (different for each
>    client) that ensures that clients don't synchronize with each other and
>    generate new addresses at exactly the same time ...
> 
> DESYNC_FACTOR is defined as:
> 
>    DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
>    It is computed once at system start (rather than each time it is used)
>    and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
> 
> First, I believe the RFC has a typo in it and meant to say: "and must
> never be greater than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE)"
> 
> The reason is that at various places in the RFC, DESYNC_FACTOR is used in
> a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or
> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be
> smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of
> these calculations to be larger than zero. It's never used in a
> calculation together with TEMP_VALID_LIFETIME.
> 
> I already submitted an errata to the rfc-editor:
> https://www.rfc-editor.org/errata_search.php?rfc=4941
> 
> The Linux implementation of DESYNC_FACTOR is very wrong:
> max_desync_factor is used in places DESYNC_FACTOR should be used.
> max_desync_factor is initialized to the RFC-recommended value for
> MAX_DESYNC_FACTOR (600) but the whole point is to get a _random_ value.
> 
> And nothing ensures that the value used is not greater than
> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE), which leads to underflows.  The
> effect can easily be observed when setting the temp_prefered_lft sysctl
> e.g. to 60. The preferred lifetime of the temporary addresses will be
> bogus.
> 
> TEMP_PREFERRED_LIFETIME and REGEN_ADVANCE are not constants and can be
> influenced by these three sysctls: regen_max_retry, dad_transmits and
> temp_prefered_lft. Thus, the upper bound for desync_factor needs to be
> re-calculated each time a new address is generated and if desync_factor is
> larger than the new upper bound, a new random value needs to be
> re-generated.
> 
> And since we already have max_desync_factor configurable per interface, we
> also need to calculate and store desync_factor per interface.
> 
> Signed-off-by: Jiri Bohac <jbohac@...e.cz>

Applied.