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.
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.
Erik
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
