João Lucas <jlucas@xxxxxxxxxxx> wrote:
> On Jan 24 12:36, Michael Richardson wrote:
>> João Lucas <jlucas at disroot.org> wrote: > Hello,
>>
>> > The purpose of this patch is to allow configuring wpa_supplicant to
>> generate > pseudo-random MAC addresses by hashing (sha256) the SSID
>> together with the > permanent address, just like iwd does when the
>> AddressRandomization option is > set to "network". This allows having
>> a unique consistent address for each > network without the need for
>> additional per-network manual > configuration.
>>
>> Thanks. This would result in per-network-generated MAC: PNGM. Please
>> see:
>> https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/
>> section 6 ---
> While the end result would be similar in most cases, the linked
> document does mention that PNGM should be stored on non-volatile
> storage, which this patch does not do since it derives the address each
> time.
Your method effectively is using something stored in non-volatile storage
(the permanent mac address), with a hash... so it effectively has the same
effect.
Mostly, I just want you to use consistent terminology!
That's why I constributed that section to that RFC.
> If we were to break compatibility, we could get rid of RANDOM_SAME_OUI
> (which could still be achieved by using RANDOM together with the
> appropriate range option) and put DERIVED_FROM_ESS (or whatever we end
> up naming it) in its place (mac_addr=2), which would solve the
> INT_RANGE problem that I explained in the cover letter.
I think you could break compatibility: my guess is that very few are using it
so far, and most that are, would probably prefer a more standard method.
(I also think SAME_OUI might be harmful: one of the reasons the IEEE decided
they needed to standardize how addresses were randomized was that onlookers
couldn't tell iPhone from Android)
Yes, this might mean for some systems that if you removed the option, their
mac address might change, and so maybe that's something that shouldn't happen overnight.
>> (Note that one would ideally use an entirely random mac address when
>> soliciting for networks.)
> Yes, and if I understand it correctly, that can already be achieved by
> setting preassoc_mac_addr to 1 or 2. Not sure if it would make sense to
> enforce it with PNGM, if that's what you're suggesting.
I think that it would be nice to set preassoc_mac_addr that way, if it's not
explicitely set to already.
The MADINAS documents do not deal with access point address randomization,
btw, as that side of things has many other issues.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
