From: Hannes Frederic Sowa <hannes@stressinduktion•org>
To: "Bjørn Mork" <bjorn@mork•no>
Cc: netdev@vger•kernel.org, 吉藤英明 <hideaki.yoshifuji@miraclelinux•com>
Subject: Re: [RFC] ipv6: use a random ifid for headerless devices
Date: Mon, 14 Dec 2015 22:30:44 +0100 [thread overview]
Message-ID: <566F3504.6050908@stressinduktion.org> (raw)
In-Reply-To: <87d1ugzs3f.fsf@nemi.mork.no>
Hello,
On 08.12.2015 19:57, Bjørn Mork wrote:
> Hannes Frederic Sowa <hannes@stressinduktion•org> writes:
>> On 05.12.2015 20:02, Bjørn Mork wrote:
>>> Hannes Frederic Sowa <hannes@stressinduktion•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 :)
Sorry for answering so late...
What do you think about simply using IN6_ADDR_GEN_MODE_RANDOM?
>>> 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.
I actually missed that. Shortly before sending the patch I decided to
allow to reinitialize the stable_secret. Before I had a check in there
to not being able to rewrite the stable_secret after it became
initialized. So we are good here. Sorry for the confusion.
> 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.
Thanks!
> 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?
Nope, that is a good point. I think we should do that unconditionally.
If we have a stable secret set, which we can use, we always should use
this address generation mode. Can you send the addition of this as a
separate patch so we can propose it for stable? Otherwise I can do that,
too.
>> 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.
Ok, your argument makes sense.
> As long as we can manage to introduce this without changing any existing
> behaviour, of course.
Besides the naming I think your patch looks fine.
Thank you,
Hannes
next prev parent reply other threads:[~2015-12-14 21:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 11:55 [RFC] ipv6: use a random ifid for headerless devices Bjørn Mork
2015-11-30 12:01 ` 吉藤英明
2015-11-30 13:55 ` Bjørn Mork
2015-12-01 7:39 ` YOSHIFUJI Hideaki
2015-12-01 11:22 ` Hannes Frederic Sowa
2015-12-03 19:29 ` Bjørn Mork
2015-12-04 10:41 ` Hannes Frederic Sowa
2015-12-05 19:02 ` Bjørn Mork
2015-12-08 13:44 ` Hannes Frederic Sowa
2015-12-08 18:57 ` Bjørn Mork
2015-12-14 21:30 ` Hannes Frederic Sowa [this message]
2015-12-14 21:43 ` Bjørn Mork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566F3504.6050908@stressinduktion.org \
--to=hannes@stressinduktion$(echo .)org \
--cc=bjorn@mork$(echo .)no \
--cc=hideaki.yoshifuji@miraclelinux$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox