Subject: Non-unique MACs

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 07:35:12 +1300

Since we're once again talking about uniqueness of IEEE addresses,
here's the text from draft-ietf-6man-ug, plus the URL references
that would go with it if the RFC Editor liked such URLs:

Firstly, there are recurrent reports of manufacturers
assigning the same MAC address to multiple devices.
(for example, see slides 63 and 64 at
https://speakerdeck.com/hdm/derbycon-2012-the-wild-west).

Secondly, significant re-use of the same virtual MAC address is reported
in virtual machine environments. (for example,
http://enterpriseadmins.org/blog/scripting/virtual-machines-with-duplicate-mac-addresses).

Once transformed into IID format (with "u" = 1) these identifiers would
purport to be universally unique but would in fact be ambiguous.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 12:18:51 -0800

Hi, Brian,

Thanks for stating this so clearly ;-)

Cheers,
Fernando

On 11/04/2013 10:35 AM, Brian E Carpenter wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2013 19:15:16 -0500

Brian, thanks for the references to the duplicate MAC problem.  
Dave Thaler asked for use cases, and I have a number of them.

I'm not sure that I have time to write them down in detail here, but if you
have questions, I could expand significantly upon them.  One of Dave's
questions was, "what did we do for IPv4", and let me tell me my answer from a
time in 2007 when I was deploying thousands of virtual machines (as virtual
desktops):

1. It was impossible in IPv4, which is why we deployed IPv6 on the
    management/storage network.   It was a killer app for IPv6.
    (Also, all of the RFC1918 address space was, in general, in use
     in the kinds of places that we needed to deploy to.)
   Since I was in charge of the virtual machine automation, I was
   in control of assigning the lower OUI, and while we started
   using 10:00:00, we later realized that an acquistion already
   owned their own OUI.
    
2. When I have a problem with a (physical) system, often I've never actually
   seen the system.  I could go ask the router what the neighbour cache says,
   and then ask the switch what port it's on, and then ask the remote hands
   to trace the cable, or I could just say, "10:00:00:ab:cd:01" is broken,
   and I know that this got printed on the back of the case.  I can do this
   now.  True, this is a physical machine, which I bought, and yes, they
   addresses could be duplicated,  but they would have to be duplicated in
   the same cabinet, and further, I was tracking physical servers by mac addreses.
   (And the PXE/TFTP/DHCP boot process needs that mac address to be unique, btw)

3. Deploying VoIP phones to customers.  We bar code scan the boxes and ship
   to customers, and the rest is configured by various protocols (tftp being
   a common one, but https URL via DHCP option much preferred).   In one
   case, a vendor actually sent us a csv file of ethernet addresses, and the
   crate of phones was shipped directly to the customer.
   (Sadly, this was all IPv4, and the https: URL formed included the mac
   address.  This is ultra common in SIP handsets. Sadly, due to NAT and lack
   any binding between layer-2 and layer-3 addresses, the phone configuration
   and therefore SIP credentials is vulnerable to random people using wget.
   Being able to use src IP, as weak as that really is, would still be a
   major improvement).

   I agree that vendors could a different algorithm, and could put a
   different address on the outside of the box.

   I also refer you to: 
   http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf
and:
   http://datatracker.ietf.org/doc/draft-jennings-core-transitive-trust-enrollment/
(sadly, expired)

   this does not depend upon EUI-64 in the address field, again validating
the point that things can work.... but again, finding the device that is out
in the floor by a handle which not the mac address, and is hard for someone
not on that layer-2, is a major operational support issue.

4. BTW: LLNs based upon 15.4 usually will replace their 64-bit (yes: 64) MAC 
   with a PAN controller allocated 16-bit MAC.  This is to reduce bit count.
   The 16-bit MAC will then be used for link local addresses, because it's
   got more zeros, and Header Compression will do a better job...  so being
   on the layer-2 doesn't even guarantee that you can find out the actual
   MAC.  I believe that this is gonna be a big deal when you send the
   technician to crawl through the ceiling looking some broken mote,
   and they won't even have an accurate MAC to look for...

Brian E Carpenter <[email-masked]> wrote:
    > Firstly, there are recurrent reports of manufacturers assigning the
    > same MAC address to multiple devices.  (for example, see slides 63 and
    > 64 at https://speakerdeck.com/hdm/derbycon-2012-the-wild-west).

    > Secondly, significant re-use of the same virtual MAC address is
    > reported in virtual machine environments. (for example,

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works