Dear colleagues: The discussion on confusion re addressing reminded me of some earlier traffic on the same matter - cf. my email as of June 12, 2009, 12:33pm EDT below. In short: systems can be designed so as to make manufacturing errors and counterfeiting almost surely detectable.
Best regards, Rene [excerpt of email Carsten Bormann as of November 9, 2009] > I didn't understand the reasons presented why we need DAD. The last I > remember was "there might be counterfeit nodes that have the same MAC > EUID". That particular argument doesn't make any sense to me, but I > may have missed others that make more sense. That depends. When we still said that the IPv6 address was hardwired to the EUI-64, the only concern was duplicate EUI-64s. How do these happen? 1) manufacturing errors. This has happened often enough in Ethernet space that DAD was made mandatory in 4861. 2) counterfeiting. Counterfeiters have a strong interest to make their products look a lot like the real thing, and for that very reason can't coordinate EUI-64 space usage with the real vendor, so it is quite likely that they will hit the same EUI-64s. Is that a problem? In the network element space, counterfeiting of expensive equipment (e.g., made by Cisco) is a very real one. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rene Struik Sent: Friday, June 12, 2009 12:33 PM To: Richard Kelsey Cc: [email protected] Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]) Hi Richard: A simple approach avoiding duplicate device identifiers would be to register devices with a registration authority and hand out device certificates that bind the device id with public/private keying material. If devices can only gain access to a network by presenting their public key certificate, this would push counter-feit devices off the cliff, since the registration authority would not allow registration of more than one device with the same device id. (Obviously, one can still try and clone a device by trying and extract private keys as well and copying this info to a number of devices, all with the same device id, something - if deemed to be a real risk - to be dealt with by proper implementation security and security techniques along the supply chain.) Best regards, Rene -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Kelsey Sent: Friday, June 12, 2009 11:18 AM To: Rene Struik Cc: [email protected] Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]) From: Rene Struik <[email protected]> Date: Thu, 11 Jun 2009 16:44:46 -0400 One cautionary node: in my mind, secure, yet easy to use device configuration and trust lifecycle management relies on devices to be uniquely identified in a static way, in a vendor independent fashion. Sadly, as I learned on another part of this thread, it appears that we may not be able to rely on having static, globally-unique identifiers. Manufacturers of counterfeit-branded devices have a disincentive to cooperate. As such, this assumes a globally unique name space across all nodes. This suggests that "globally unique" is not a proper adjective for "16-bit addresses" (unless you wish global device deployment to be limited to 64k devices only [which I hope not...]). "Globally unique" was indeed incorrect. I should have said "unique within the LoWPAN" or some such. -Richard Kelsey _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
