Hello Alberto,
I was wondering if the following is really an issue for SEND hosts doing DAD, and if it is worth to be protected (this arose when defining SAVI operation for SEND):
This is the attack I described to the list in this mail: http://www.ietf.org/mail-archive/web/cga-ext/current/msg00057.html And then a thread (providing some other solutions): http://www.ietf.org/mail-archive/web/cga-ext/current/msg00075.html
I don't see in RFC 3971 any countermeasure to this. Am I right?
The spec does not say how to counter this. However, in a current implementations, adding a fix seems pretty straightforward.
Do you think this is a problem? If so, do you think it needs to be fixed?
IMHO, RFC 3971-bis should explicitly provide a solution to counter this attack.
A simple solution would be for the possible victim to discard received DAD NSOLs for the same address that it has in tentative state that have equal <public key, nonce, timestamp> than the DAD NSOL that it had sent before. (The probability of a legitimate collision in which another host that generates a DAD NSOL with the same public address, nonce and timestamp should be really low).
Just comparing the nonce value should suffice.
For ND (unsecured), this case is also a problem, but for ND you can't decide by looking to a received DAD NSOL when it is an attack or just a real collision (and this could be also an incentive to use SEND, of course).
Plain ND is not secure anyway. Some scenario are using a network setup where each nodes are on a different port of a switch. If the switch was to support Multicast Listener Discovery, the attacker will never get to receive the DAD NS message to begin with. As stated in: http://www.ietf.org/mail-archive/web/cga-ext/current/msg00077.html Hence, it will preclude the attack. Am I wrong ? Regards, Tony _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
