netdev - Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on RAWIP devices

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]

Message-ID: <94773789691f384f93975f599ea01e5c@codeaurora.org>
Date:   Fri, 08 Jun 2018 18:34:37 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     Lorenzo Colitti <lorenzo@...gle.com>
Cc:     YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on
 RAWIP devices

> Actually, I think this is fine. RFC 7136 clarified this, and says:
> 
> ======
>    Thus, we can conclude that the value of the "u" bit in IIDs has no
>    particular meaning.  In the case of an IID created from a MAC 
> address
>    according to RFC 4291, its value is determined by the MAC address,
>    but that is all.
> [...]
>    Specifications of other forms of 64-bit IIDs MUST specify how all 64
>    bits are set, but a generic semantic meaning for the "u" and "g" 
> bits
>    MUST NOT be defined.  However, the method of generating IIDs for
>    specific link types MAY define some local significance for certain
>    bits.
> 
>    In all cases, the bits in an IID have no generic semantics; in other
>    words, they have opaque values.  In fact, the whole IID value MUST 
> be
>    viewed as an opaque bit string by third parties, except possibly in
>    the local context.
> ======
> 
> That said - we already have a way to form all-random IIDs:
> IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type
> ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to
> less special-casing.

Hi Lorenzo

In v2 of this patchset, I used addrconf_ifid_ip6tnl() similar to
IP6 Tunnels / VTI6, so I didnt need that way of generating the IID.
addrconf_ifid_ip6tnl() also provides fixed IIDs during the lifetime of 
the
net device while IN6_ADDR_GEN_MODE_RANDOM generates different addresses.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project