Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-Privacy] using only 24 bits of random MAC



Dan, Paul,

 

From: Paul Lambert [mailto:paul@xxxxxxxxxxx]
Sent: Wednesday, October 01, 2014 1:25 PM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] using only 24 bits of random MAC

 

From: Dan Harkins <dharkins@xxxxxxxxxxxxxxxxx>
Reply-To: Dan Harkins <dharkins@xxxxxxxxxxxxxxxxx>
Date: Wednesday, October 1, 2014 at 8:51 AM
To: "STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx" <STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-Privacy] using only 24 bits of random MAC

 

 

  Hello,

 

  As Mathieu reported today, when randomizing only 24 bits of the MAC

a collision is basically assured. We can calculate the probability of a

collision out of a pool of c when there are n people by:

 

   p(n; c) = 1 - ((c-1)/c)^(n*(n-1)/2)

 

If we are only randomizing 24 bits of MAC we end up with numbers

like this:

 

  p(500, 2^24) = 0.0074 

  p(1000, 2^24) = 0.029

  p(5000, 2^24) = 0.525  <-- worse than a coin flip

 

Even with only 500 people it's basically assured that there will be a

collision after a while. Whereas if we randomize 46 bits of MAC we end

up with numbers like this:

 

  p(500, 2^46) = 0.0000000018

  p(1000, 2^46) = 0.0000000071

  p(5000, 2^46) = 0.0000001776

  p(10000, 2^46) = 0.0000007105

  p(30000, 2^46) = 0.00000639

 

The record for most simultaneous associations in a wi-fi network is 

30,0000+ and even in that situation, assuming everyone is randomizing

MAC addresses it's still around 1:156000. Never say never but we can say

"highly unlikely."

 

  Whereas if we only randomize 24 bits we can safely say "definitely assured".

I do not think this study group wants to come up with recommendations on

how to most assuredly screw up a network. 

 

  The critical issue is not whether someone temporarily sets his MAC address

to that "owned" by someone somewhere (and I am still not convinced that

purchasers of OUIs get them with the "local" bit set), the critical issue is

whether there will be collisions on the switched network. We do not need to

assure that a randomly chosen MAC address is unique in the world, we just

need to make it as unlikely as possible that that address is already used on the

same switched network. We can't make that assurance with only 24 bits

but we can with 46.

 

  Please, let's abandon the idea of following 802.1's recommendations for

their small, local LAN randomized MAC scheme. It won't work in wireless

in the real world.

 

+1 

It’s not appropriate to hijack a global OUI and create random MAC addresses and as Dan points out potentially increases the likelihood of collisions.

Using a OUI with local bit is unnecessary and again increases collisions.

 

[JCZ] I want to clarify that what 802.1 is considering is the use the CID for this purpose, as –already- specified by the IEEE RAC: http://standards.ieee.org/develop/regauth/cid/ .

 

Strictly speaking, these are not OUIs (i.e. used to generate globally unique MAC addresses), but for our purpose they could be seen as such, since they consume 24 bits. Also we need to keep in mind that the numbers assume addresses sharing the same CID, which means potentially from the same manufacturer and in reality is less likely.

 

Having said that, I see and share your concerns about the probability of collisions in a WLAN environment. Hence, any proposal put forward from this group should be well founded and supported with as many numbers and facts as we can.

 

Finally – real local addresses can be readily identified for potential special processing in the future.  Special could mean shorter DHCP time-outs, etc.

[JCZ] This is a good point, since any numbers we have used so far assumed “permanent” MAC addresses. Now we need to consider simultaneous MAC addresses, which potentially will change in time and in an asynchronous manner.

 

Perhaps these are new metrics that we can also derive from the trial/experiment at the IETF network…

 

Regards,

 

Juan Carlos

 

Paul

 

 

 

  regards,

 

  Dan.