netdev - Re: ip-token: unable to remove a token & multi-token handling & concurrent use w/ EUI64/privacy

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] [day] [month] [year] [list]

Date:	Tue, 22 Mar 2016 18:03:24 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	"Robin H. Johnson" <robbat2@...too.org>
CC:	netdev@...r.kernel.org, hannes@...essinduktion.org
Subject: Re: ip-token: unable to remove a token & multi-token handling & concurrent
 use w/ EUI64/privacy

Hi Robin,

On 03/19/2016 07:53 PM, Robin H. Johnson wrote:
[...]
> Playing around with IPv6 tokens, I ran into a problem:
> Once you have a token set on an interface, it's impossible to remove it!
>
> # ip token set :: dev eth0
> RTNETLINK answers: Invalid argument

I'll have a look into a fix, I think this was intentional, but I currently
fail to recall a reason why (should have put a note into the commit log). ;)
The draft is pretty terse in any case, it seems as we only invalidate other
tokenized addresses, it should be okay to just remove it.

> This is a side-effect of rejecting ipv6_addr_any in inet6_set_iftoken.
>
> While this gets fixed, I have two related feature requests for this:
> - Please make it possible to configure multiple tokens on an interface:
>    Use case: Deploying local services on well-known addresses inside a
>    network without explicit prefix configuration.
> - Adding a token causes other address generation methods to be disabled,
>    this is problematic if you wish to prefer privacy addresses for
>    outbound connections.
>
> Design suggestion:
> Convert from using a single token to using a list of tokens, with an
> explicit default IPv6-any-addr (::) in the list, to represent that
> other address generation should ALSO take place (EUI64/privacy).
> Deletion of the any-addr from the list should disable EUI64/privacy
> addresses.

Seems you already have some patches, please feel free to send them. ;)

Thanks for the feedback!
Daniel