>> The two areas in which I think this proposal can benefit from some more >> discussion: >> >> Clearly, mitigating the external ND table DoS is one of the major pain >> points addressed by this. Thinking point: Is there any way to structure the >> transition from legacy ND to efficient ND in such a way that it becomes >> easier to reap this benefit? > > If not all the hosts on the link do explicit registration, then the routers > need to be able to send multicast NS messages to find those that didn't > register. > As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and > draft-ietf-6man-impatient-nud-05.txt, things can be improved if the routers > don't discard NCEs too quickly, and potentially interpret unsolicited NS > messages as a registration attempt. > > The last part is a bit problematic in general, but if a router has sufficient > memory it can definitely track which hosts it has ever heard from on the link > and thereby significantly reduce the rate at which is needs to send multicast > NS to look for previously unknown hosts.
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. 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... >> 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. 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. Grüße, Carsten -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
