Re: Software to test MAC address privacy
- From: Glen Turner <gdt gdt id au>
- To: Robert Moskowitz <rgm htt-consult com>
- Cc: Network Manager <networkmanager-list gnome org>
- Subject: Re: Software to test MAC address privacy
- Date: Tue, 5 Aug 2014 00:45:22 +0930
Robert Moskowitz wrote:
There is talk about partitioning the use of the LAS. I am against that as it increases the collision
probablity. Perhaps by usage domain.
In any case we will have to work out probe/discovery methods to discover collisions for readdressing.
Hi Robert,
I would strongly encourage you not to use the entirety of the LAS. The IEEE has already divided usage of the
LAS by the most significant byte, last I checked values 00:… through to 05:… had been used in various IEEE
documents. Simply allocate the next free most significant byte for the purposes of showing the LAS is
intended to be a random LAS. You would be doing a service if you also allocated LAS MSBs for VMs and SDNs.
Discovery protocols have been historically problematic. I would encourage you to read carefully the extensive
security analysis of IPv4 ARP, IPv6 ND and DAD.
1) Discovery protocols assume that you can trust your neighbours. You cannot trust your neighbours. For
example, a neighbour can claim to hold all of the MAC address space apart from a small amount which it can
later readily search. Or a neighbour may deny service by claiming every probed address.
2) You can write discovery protocols which do not have these issues, but they are very expensive to run and
may defeat your privacy goal (eg, require all interfaces on a ethernet to provide their MAC address upon
occassional request, then the booting host can choose a MAC address not on that list).
3) You can of course somewhat protect against misuse of discovery protocols by using features of ethernet
switches, wireless access points, etc. But no other working group has specified the required security
features of a switch port, so this is a substantial undertaking. The result is not applicable to all 802.3
systems.
4) A discovery protocol is also another protocol which has to succeed prior to establishing contact with a
partner interface. The farce of ethernet auto negotiation shows that these protocols have high demands for
robustness which are difficult to meet.
If you wish to use the entire LAS then the greatest problem of a discovery protocol running across is that
it does not solve the problem of duplicate addressing. A LAS-using protocol may be required to use a
*particular* MAC address (eg- DECnet or some SDN algorithms) and if that machine is offline when discovery is
run then that machine cannot join the network afterwards.
In short, constrain the random LASs to using a particular most significant byte to prevent collisions with
other users of the LAS.
As for the search space argument, you are arguing that a search space of 2^46 is large enough but a space of
2^40 is not.
Note that the use of the LAS is not mostly historical. Software-defined networks in data centres use LAS to
contain hierarchical forwarding information. Again, all the more reason to use the most significant byte of
the LAS to indicate the allocation intent of the LAS.
If you are doing this work because of the presence of EUI-64 addresses in IPv6 addressing then the IETF is
altering the IPv6 SLAAC specification to require randomisation of Interface IDs (typically the lower /64 of
the IPv6 address). The Interface ID is randomised on the first-ever boot of the system and then that
Interface ID is retained for the lifetime of the machine or until sysadmin action). See
http://www.rfc-editor.org/rfc/rfc7217.txt
Best wishes with your project,
glen
PS: probably best to move any further discussion off-list.
--
Glen Turner <http://www.gdt.id.au/~gdt/>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]