Hi Julien,
So I understand a node receiving a DAD NS after having sent out a DAD NS
happens when two nodes are performing DAD simultaneously as per RFC 4862.
Yes, exactly. The attacker is replaying a protected NS, faking the case
where two nodes want the same address.
If so, are you Tony suggesting that incoming DAD NS's with nonce similar to a
nonce included in an outgoing DAD NS be discarded?
Two nodes having the same Public Key could be a misconfiguration issue,
while two nodes having the same Public Key and the same nonce clearly
indicates an attacker.
The probability that two nodes ends up generating the same public-private key
should be zero unless the public key scheme is broken, so I think when a node
receives a SEND protected message where the public key is the same as its own,
the node MUST assumes the message was sent by himself and MUST discard the
message.
That's an other possibility. However, we should be careful that other
public key scheme are not used. Such as the ring signature algorithm
proposed in [1] (it's mainly a research paper), but all the node will
share the same Public Key (hence address), and this is an expected
behavior. One could argue this was useful to solve the ND proxy case
(which is now solved differently), but I think it might also be a
solution to anycast related issue SEND.
To sum up, I'm OK to check for identical Public Keys, but I would rather
see a comparison on more data (Public Key + Nonce + Timestamp).
Does that seem reasonable ?
Regards,
Tony
[1] J. Kempf, J. Wood, Z. Ramzan, and C. Gentry, “IP Address
Authorization for Secure Address Proxying Using Multi-key CGAs and Ring
Signatures,” Advances in Information and Computer Security, 2006, pp.
196-211.
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
