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: <20130820.234818.2230621827416764963.davem@davemloft.net>
Date:	Tue, 20 Aug 2013 23:48:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	nicolas.dichtel@...nd.com
Cc:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] ip6_tunnel: ensure to always have a link
 local address

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.

--
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