Message-ID: <87d1ugzs3f.fsf@nemi.mork.no>
Date:	Tue, 08 Dec 2015 19:57:08 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org,
	吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
Subject: Re: [RFC] ipv6: use a random ifid for headerless devices

Hannes Frederic Sowa <hannes@...essinduktion.org> writes:
> On 05.12.2015 20:02, Bjørn Mork wrote:
>> Hannes Frederic Sowa <hannes@...essinduktion.org> writes:
>>> On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote:
>>>
>>>> After looking more at addrconf, I started wondering if we couldn't abuse
>>>> ipv6_generate_stable_address() for this purpose?  We could add a new
>>>> addr_gen_mode which would trigger automatic generation of a secret if
>>>> stable_secret is uninitialized.  This would be good enough to ensure
>>>> stability until the interface is destroyed.  And it would still allow
>>>> the adminstrator to select IN6_ADDR_GEN_MODE_STABLE_PRIVACY by entering
>>>> a new secret.
>>>
>>> I am fine with your proposal but I would really like to see it only
>>> happen on the per-interface stable_secret instance.
>> 
>> Do you think something like the patch below will be OK?
>
> I wouldn't call it IN6_ADDR_GEN_MODE_AUTO, this doesn't say anything.
> But the idea is already good.

No, I didn't like that name either.  I just couldn't come up with
anything descriptive, short and non-redundant. "random", "generated",
"stable" are even worse.  And that's about where my imagination ended.
We need a child here :)

>> Or would it be better to drop the additional mode and just generate a
>> random secret if the mode is IN6_ADDR_GEN_MODE_STABLE_PRIVACY and the
>> secrets are missing?  Or would that be changing the userspace ABI?  This
>> is not clear to me...
>
> I would not like to do that somehow. The problem is that the stable
> secrets get written by user space probably during boot-up, but we don't
> know when. That's why I would also not set the ->initialized flag, so
> user can overwrite it to the final secret later on. We block it otherwise.

I am not sure I follow...  There is nothing preventing userspace from
initializing the secret before or after generation of the random secret.
Writing to /proc/sys/net/ipv6/conf/<iface>/stable_secret will update the
secret and set the mode to IN6_ADDR_GEN_MODE_STABLE_PRIVACY as before,
even if we have generated a random secret first.  I have verified that
this part works as expected.

I guess we should check &net->ipv6.devconf_dflt->stable_secret too
before choosing the default mode.  IN6_ADDR_GEN_MODE_STABLE_PRIVACY is a
more approproate default if a default secret is set.  IMHO, this should
really be the case without the proposed change too, but it isn't. The
current behaviour confuses me: Setting 'default' changes all existing
interfaces, but does not change the default for new interfaces. Is that
right?

> My proposal would be to use the stable privacy generator in case the
> device does not have a device address for EUI-48 generation with a
> secret which we simply generate on the stack. Let's factor out the part
> of the generator which depends on the inet6_dev and cnf bits for that.

Not sure I get this part either.  The point was to have stable addresses
for the lifetime of the netdev.  We can generate the secret on the
stack, but we will still need to stash it somewhere.  That could of
course be to a new field.  But I don't see the point since there is no
way you can combine this mode with IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
Only one mode can be active at, and that mode can then own the secret.

As long as we can manage to introduce this without changing any existing
behaviour, of course.



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