In your letter dated Tue, 12 Jul 2011 09:56:33 -0700 you wrote: >On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote: >> What does that mean? Each time I connect my laptop to a network, an = >operator >> shows up from behind the bushes and configures the right parameters? > >first off, beaconing is clearly not appropriate for all environments. so = >I wouldn't expect a laptop to do it at all unless you were explicit in = >your desire to do so. the goal was also to make the mechanism backward = >compatible with existing ND behavior, where such a message unsolicited = >would be grounds for kicking off a neighbor discovery process.
>From a presentation perspective, I think it would be better if you start with the general solution before moving to more specialized ones. (I'll ignore this part for now) >it's the router's ndp cache not the laptop that's the target of the dos. I know. But it is vital that my laptop's MAC gets into the router's neighbor cache. So I assumed that this was done using beaconing. >> IMHO, what is needed is to write a document that lists changes and = >additions >> relative to the neighbor discovery rfc, such that by default, routers = >and >> hosts can be protected against this attack. > >7.3 and 7.4 are in fact proposals for changes to 4861. They could be = >split into a separate document. goal was to get something out so that we = >could shoot holes in it. Moving it to separate document is one thing. Moving it to its own section and using more formal language wouldn't hurt. In particular try to make clear what you want to add to what sections of RFC-4861. Now to Section 7.4. Are you seriously suggesting that on a large network, every host when it boots sends a multicast to the all-routers address? You have 6000 hosts that wake up after a power failure and they just randomly multicast to the all-routers address? And then what? How does this stay in all of the routers' neighbor caches for ever? Except that hosts can use privacy address, so more and more addresses have to become locked in the routers' caches. What if a router reboots? >implementation advice in 7.1 7.2 are things that can be done without = >making changes to the way that NDP works today. Even then, if doing things in the right order is critical, that should be considered part of the protocol. Even if the bits on the wire remain the same. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
