Re: Software to test MAC address privacy



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]