On Nov 3, 2009, Eric Levy-Abegnoli wrote: >> Let's be a bit more specific here. In what way would a non-SEND- >> capable >> SAVI device break RFC 3971? Alberto has mentioned one case -- when a >> SEND host's DAD fails for the second time due to an unsecured >> Neighbor >> Advertisement, then the SEND host will configure the IP address, >> yet a >> non-SEND-capable SAVI device would block the IP address. Is this the >> issue you are referring to? Then we should discuss whether or not >> this >> is acceptable. Or are there more issues you are thinking of? >> > > The sole purpose of CGA is to enable a CGA-capable node to prefer > CGA-prooved NDP message over a none prooved one. If the savi device > does > first-come-first-serve, and is not able to verify (and prefer) CGA > credentials, then there are plenty of scenarios where it will keep the > non CGA owner entry and discard traffic from the legitimate: basically > all scenarios where the non-CGA came first. But all of these scenarios are about the same issue: When a SEND host's DAD fails for the second time due to an unsecured Neighbor Advertisement, then the SEND host will configure the IP address, yet a non-SEND-capable SAVI device would block the IP address. The same holds for the attack scenario that you described in your email. The question is hence: What do we do about this issue? Is it negligible? Is it significant enough to warrant building SEND support in all SLAAC SAVI devices? Should we find some tradeoff? I think your attack scenario shows that the situation is not negligible. On the other hand, many of us feel that full-fledged SEND support would make SLAAC SAVI devices too expensive. So how would a reasonable tradeoff (Alberto calls it a "SEND-compatible mode") look like? - Christian
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.