netdev - Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F

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: <1383002583.28991.19.camel@dcbw.foobar.com>
Date:	Mon, 28 Oct 2013 18:23:03 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	hannes@...essinduktion.org, jiri@...nulli.us, vyasevich@...il.com,
	netdev@...r.kernel.org, kuznet@....inr.ac.ru, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, thaller@...hat.com,
	stephen@...workplumber.org
Subject: Re: [patch net-next] ipv6: allow userspace to create address with
 IFLA_F_TEMPORARY flag

On Mon, 2013-10-28 at 18:16 -0500, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> > Date: Sun, 27 Oct 2013 17:48:35 +0100
> > 
> > > A temporary address is also bound to a non-privacy public address so
> > > it's lifetime is determined by its lifetime (e.g. if you switch the
> > > network and don't receive on-link information for that prefix any
> > > more). NetworkManager would have to take care about that, too. It is
> > > just a question of what NetworkManager wants to handle itself or lets
> > > the kernel handle for it.
> > 
> > How much really needs to be in userspace to implement RFC4941?
> > 
> > I don't like the idea that even for a fully up and properly
> > functioning link, if NetworkManager wedges then critical things like
> > temporary address (re-)generation, will cease.
> 
> Honestly, I'd be completely happy to leave temporary address handling up
> to the kernel and *not* do it in userspace; the kernel already has all
> the code.  There are two problems with that though, (a) it's tied to
> in-kernel RA handling, and (b) it's controlled by a CONFIG option.  Both
> these are solvable.
> 
> First off, what's the reasoning behind having IPv6 privacy as a config
> option?  It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config?  Or is it just for
> smallest-kernel-ever folks?
> 
> Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> that for some new static address, that the kernel should create and
> manage the temporary privacy addresses associated with its prefix?

Except that we've run out of IFA_F_* flags already, since it's a u8 and
there are already 8 flags.  What to do?

Dan

> Dan
> 
> > All that seems to matter is the secret used to generate the temporary
> > address sequence, and perhaps things like site specific lifetime
> > parameters.  These are things userland can send to the kernel in
> > netlink messages.
> > 
> > Full disclosure that I am saying this from the perspective of someone
> > who believes that one of the biggest mistakes ever was allowing the
> > core of DHCP to be done in userspace.
> > 
> > Right now every ipv4 DHCP user ends up with their interface in
> > promiscuous mode.  The DHCP client implementations are huge non-
> > trivial bodies of code, and getting them to adopt the changes necessary
> > to not put the interface in promiscuous mode is harder than pulling
> > teeth.
> > 
> > If at least the DHCP protocol communications part were in the kernel,
> > on the other hand, we could remove the problem quite swiftly.
> > 
> > This problem has existed for more than a decade, btw.  There simply
> > exists no will to fix it properly, even after all this time, because
> > breaking the ice on those DHCP client code bases in userbase is hard.
> > 
> > So I want to see less fundamental stuff about interface configuration
> > and address assignment in userland, not more.
> > --
> > 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
> 
> 
> --
> 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


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