On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote: > In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote: >> You can't have two-party communication have only one part (the router) = >> perform all the actions. > > So, in my proposal, the router sends out a request for help. And all of its > neighbors respond with a Neighbor Solicitation. > >> Is there a specific part of the above draft that you think should be = >> changed? In what manner? > > Well, add my proposal :-) Formally request a change to the Neighbor Discovery > RFC that allows this to happen. > >> I happen to think that it's not desirable to have any network element = >> under attack, but the ideas in the draft seem to be well thought out, = >> but perhaps not clearly stated enough for your needs? (and with the = >> least amount of protocol changes necessary, infact i believe only one, = >> the rest could be seen as implementation details that would result in a = >> lab failure and failure of RFP with noncompliant vendors). > > I think they are certainly not stated clearly enough. But also don't think > they go far enough. As far as I can tell, the draft does not contain a > protocol > that will always work. > > It contains a number of suggestions that to some extent mitigate the problem. > > For example, > > "Hosts MAY be configured to send unsolicited Neighbor advertisement > "at a rate set at the discretion of the operators. The rate SHOULD > "be appropriate to the sizing of ND cache parameters and the host > "count on the subnet. An unsolicited NA rate parameter MUST NOT be > "enabled by default. > > 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. > What if it doesn't happen? Then my laptop is not protected a case of a DoS on > the router? it's the router's ndp cache not the laptop that's the target of the dos. > 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. implementation advice in 7.1 7.2 are things that can be done without making changes to the way that NDP works today. > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
