netdev - Re: [PATCH RFC] ipv6: stable privacy addresses

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Dec 2013 12:50:33 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florent Fourcot <florent.fourcot@...t-bretagne.fr>
Cc:	netdev@...r.kernel.org, fgont@...networks.com
Subject: Re: [PATCH RFC] ipv6: stable privacy addresses

On Fri, Dec 13, 2013 at 11:33:23AM +0100, Florent Fourcot wrote:
> Do you not provide a configuration via netlink for the secret?

I definitely will provide a netlink interface. I already have a patch here but
I am not sure how the interface will work out in the end. See below.

> > +config IPV6_ADDRESS_GEN_MODE_STABLE_PRIVACY_V1
> > +       bool "Stable privacy address generation v1"
> > +       help
> > +         Stable privacy address generation mode v1. Further
> > +         information can be found here:
> > +	 http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-16
> > +
> > +	 This option may need support from distributions to install
> > +	 the stable secret early at boot up (otherwise link-local
> > +	 addresses will be generated too late). If you don't have
> > +	 services depending on link-local addresses on boot-up you can
> > +	 activate this mode and install the stable secret any time
> > +	 later by hand by writing it to
> > +	 /proc/sys/net/ipv6/stable_privacy_secret.
> > +
> 
> Here is your documentation inconsistent with before. The right file is
> probably /proc/sys/net/ipv6/stable_address_secret
> 
> You configuration is for all interfaces the same, isn't? I would like a
> configuration possibility per interface, to mix EUI64 and stable privacy
> addresses on the same device.

You mean like EUI-64 link-local and privacy-stable ones for global scope?
This indeed does sound useful.

> In the same way, the configuration of the secret per interface could be
> useful (simple example: two NIC on the same LAN).

Hmm, I thought about that too, but have not found a valid reason to support
it yet, given the numerous other configuration possibilities.

My current problem is how to make this interface as robust as possible to
use so that distributions can support it.

I just started coding support for tracking DAD-errors accross reboots so
e.g. if a privstbl address has two DAD conflicts before it stabilzes,
it should get the same one after reboot. Ideally we would serialize
this information into user-space and apply it on next boot. But what key
should we use to store the dad-conflicts (MAC or interface name etc. or
make it even configurable?). Should we store information on interfaces
which are not yet registered too, or always kick link-local generation by
hand? When should we store those numbers? If we only do that at shutdown
time we may have lost some manually destroyed interfaces already.

I have a similar problem with virtual interfaces. It would be better to
identify them by name and not by mac-address. Also we should include the name
in the hash, so we could have different kind of hashes per interface.

The hash itself needs to be stable and one particular hash version must not get
touched after release, otherwise we could change people's IPv6 addresses
accross upgrades.

The combination of all those options call for a very complex interface. In the
end I hoped to get basic support into the kernel and leave complex policies to
user-space (that's out of scope for this patch but I already have some ideas).

> > -static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
> > +static void addrconf_dad_stop(struct inet6_ifaddr *ifp, bool dad_failed)
> > 
> 
> The passage of dad_failed from int to bool is not directly connected
> with this feature, can you maybe split it in another patch?

I guess I should do that. But in the end I am almost always too lazy to
submit such patches then. ;)

I'll also improve the documentation in the next versions, thanks for the
corrections! It seems I did not update it regullary enough every time I did 
change in the code.

Thanks for review,

  Hannes

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