Christian Vogt a écrit :
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?
I don't think we need "full-fledged SEND support". All what is needed
is the capability to verify a sha1 hash and a rsa-signature. **That**
is negligeable compared to full-fledge SeND or to everything else
required to implement savi slacc or dhcp. And there is plenty of open
source to achieve these minor features.
So the tradeoff would be to require CGA and RSA verification (this is
pure algorithmic and entirely stateless), and prefer entries what carry
these credentials. I really don't see that as a big deal.
We (SeND work) have defined a realistic incremental deployment scenario
for SeND ("transitionning mode"). And we start seeing it happening. The
security is left to end-nodes, and network admin have little ways to
know which end-nodes are using CGA addresses. As soon as a
savi-not-CGA-capable device is going to be deployed, these (few)
end-nodes doing SeND will be as vulnerable as regular ND nodes. And
these nodes will have no way to know that a savi-device is messing
with ND.
**We are moving the security decision from host to the switch, with
less security, and no way to communicate this between each other**
I am worrying that if we don't make CGA verification a MUST, we are
giving a clear message that SeND is useless. What is the value of a
security mechanism that prevent another stronger one to operate?
Eric
- Christian
|