Hi Erik > On 05/31/10 11:59 PM, Pascal Thubert (pthubert) wrote: > > Hi Erik > > > >> I don't see how the additional complexity of oDAD makes anything > > different > >> in 6lowpans; as I stated in an earlier email I think it is impossible > > to detect > >> duplicate EUI-64's in a 6lowpan. > > > > [Pascal] Yes, I've read that part and I'm afraid I partially disagree. > > Partially because it depends what you're fighting against. To fight > > against attacks is difficult and probably requires crypto. > > OTOH, if the most probably cause of dups is erroneous config or > > forged hardware, and we are looking at preventing that sort of error, > > then a simple boot-time random can help tremendously. > > The simplest method is to place the boot-time random in all > > registrations. A registration with the wrong random fails. > > So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers with > a lifetime of say three days. > Then the host is rebooted, comes back up and uses boot-time-random=Z. > > Then it will fail to register its EUI-64-based, since it will be a duplicate. > > The issue is that the information used to identify the node (to tell two nodes > apart) must be in stable storage. > That probably means that a spoofed/cloned host would duplicate that > information as well. > > Hence adding more information doesn't seem to help. > > > More complex, > > and slightly more secure, place it in the first registration and then > > include it in a signature. > > The consequence is that a device with no permanent memory that reboots > > will have to wait for the end of its current registration before it > > can reregister. > > That seems broken. One could envision a scheme where the first registration > involves creating some key that becomes shared between the host and the > network. But such a case I think we MUST require that they key be stored in > stable storage on both the host and the routers.
[Pascal] In the simplest instance I expected to use the rnd as a simple correlator, though. But if it helps to call it a key let's call it that way. We seem to have problems with agreeing on names :) > But before we embark on creating some new and complex scheme for doing > this, it would make sense to understand the security aspects of the whole > network. It might not make any sense to merely try to secure the DAD and > the registrations, if the L2 network is completely open. And if the L2 network > is secure, then it might not add anything to try to secure the > DAD/registrations. > > > Once we detect the error, the real trouble is to define the backup > > strategy. What does the node do then? > > If DAD fails for a short address, then the host should try a different short > address. Ditto if it is a RFC 4941 temporary address. [Pascal] I was asking about the EUI-64 based address. A node registers, and the router says no. Like I said, most probable cause are misconfig and silicon forgery. What's next for this node? Seems to me that the devices can use a random 64-bit Identifier and try again, at least to be able to notify. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
