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:	Wed, 21 Aug 2013 11:02:52 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	nicolas.dichtel@...nd.com
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:
> Le 21/08/2013 08:48, David Miller a écrit :
>
>> Applied, but this brings up an issue I keep noticing.
>>
>> We talk about eth_random_addr() and "uniqueness" together all the
>> time, but the former never implies the latter.
>>
>> And we're going to run into situations where any conflicts generated
>> by this random address generater will cause reall failures.
>>
>> Therefore we'll have to create a system to prevent them.  Probably
>> using some simple table that keeps track of the addresses we've
>> generated.
>>
> Ok, I will look at this.

Are eth_random_addr() collisions really any different than interfaces
having the same address for other reasons? Reality is that we never can
trust a mac address to be truly unique, regardless of source.  And most
of the time it doesn't matter.  There is no problem with two interfaces
having the same link local address as long as they are on different
links, for example.

What's important is that we deal with collisions gracefully in cases
where they do matter, allowing an administrator to fix the issue.  I
believe we already do that on DAD failure with any mac address derived
link local address, disabling IPv6 and logging the reason. 


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ