On 11/1/12 11:23 PM, Carsten Bormann wrote:
But most of this only helps with the addresses for which hosts actually exist.
In the transition, routers still need to implement rate-limiting on their
multicast NS.
(With Efficient-ND, hosts defer to routers for finding other hosts.) Maybe we
should mention that.
We can definitely mention that.
Using any heuristic (tracking hosts based on unsolicited NS, MLD, whatever) to
track existing hosts (more specifically: existing host addresses) is good.
Routers can limit their NS rate-limiting behavior to those hosts for which they
have heard nothing. So this is a valid strategy to point out. (Specific
heuristics are orthogonal to this draft, though.)
But the attack is about hosts that don't exist, so inducing multicast NS rate
limiting is still an effective DoS on the router finding hosts/addresses not
yet discovered (there are many more non-existing hosts than additional
addresses). Improving the discovery heuristic thus mitigates the DoS.
>
(Note that attacks on the discovery heuristic are possible, but these would be
inside attacks.
The bad thing about the ND table attack is that any Internet host can carry it
out.)
Not being subject to not being found due to multicast NS rate-limiting, of
course, is a deployment incentive on the host side...
Agreed.
For DC applications, the assumption of uniqueness of the EUI-64 probably
requires some more thinking. VMs get copied all the time, and it is way too
easy to copy this kind of config info in the process.
I don't think the EUI-64 is different than the IEEE-48 MAC address. In fact the
for Ethernet the EUI-64 is derived from the MAC address.
And if cloning a VM results in keeping the same MAC address then things will
not work well even for IPv4.
Sure. People do have problems with this on IPv4, too. But can (should?) we do
better?
If yes, that would be another deployment incentive for Efficient-ND.
I don't think we can do better. When you clone a VM you still want the
new VM to have a distinct identity compared to the origin of the clone.
Either that identity is external to the VM (such as a MAC address that
is controlled by the hypervisor), or internal to the VM (such as a
configured DHCP client-id in some config file).
In the case of an internal identity you'd need to be able to set a new
one as part of a clone.
This isn't unique to IP-related config.
In many cases when you clone a VM you'd like it to have a different
hostname and probably a unique ssh key.
In summary, none of these are problems with the draft -- I'm just pointing out
that if we can do something beyond what we have, these are ways to increase the
deployment incentive.
Understood.
Thanks,
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
