netdev - Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address

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]

Message-ID: <52146EE9.1060101@6wind.com>
Date:	Wed, 21 Aug 2013 09:40:25 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local
 address

Le 21/08/2013 08:48, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> Date: Tue, 20 Aug 2013 12:16:06 +0200
>
>> When an Xin6 tunnel is set up, we check other netdevices to inherit the link-
>> local address. If none is available, the interface will not have any link-local
>> address. RFC4862 expects that each interface has a link local address.
>>
>> Now than this kind of tunnels supports x-netns, it's easy to fall in this case
>> (by creating the tunnel in a netns where ethernet interfaces stand and then
>> moving it to a other netns where no ethernet interface is available).
>>
>> RFC4291, Appendix A suggests two methods: the first is the one currently
>> implemented, the second is to generate a unique identifier, so that we can
>> always generate the link-local address. Let's use eth_random_addr() to generate
>> this interface indentifier.
>>
>> I remove completly the previous method, hence for the whole life of the
>> interface, the link-local address remains the same (previously, it depends on
>> which ethernet interfaces were up when the tunnel interface was set up).
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@...nd.com>
>
> 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.
--
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