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?

What if it doesn't happen? Then my laptop is not protected a case of a DoS on
the router?

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.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to