Hi,
While I appreciate the enthusiasm for the idea of stateless neighbor discovery, none of these changes (versions 02 through 04) have gone through me. I also assume that it is up to me as to whether Oliver becomes co-author or not, as versions 00 and 01 were my individual work. I'd appreciate some advice from the Working Group chairs as to what to do in this situation. Oliver, I think your Hashed SLND idea is different enough that it should be in a separate ID, which I think should reference rather than be derived from a copy of my ID. I have two concerns about it - firstly, it would significantly increase the processing load on the control plane, due to the calculations of hashes, which may create another opportunity for an attacker to DoS the control plane of the router by exhausting it's CPU resources. Secondly, it would require a router to assign those addresses to it's interface for at least as long as the NS/NA transaction can take place, otherwise the incoming NA would be dropped, and as these hashed addresses are derived from the destination address that triggered the NS/NA transaction, this could also create a DoS opportunity, as temporarily assigning these addresses to the router's interface would also require state that could be exploited. Ultimately, I think a host registration protocol is necessary to properly solve the problem, as it ensures off-link hosts can't create any unnecessary state or processing on routers, allows full logging of hosts that attach to the network (which stateful DHCPv6 won't do because it doesn't record host static address assignments), and prevents on-link hosts from spoofing source addresses that fall within the local subnets, something that BCP38 can't do. My proposal is about mitigating the DoS opportunity for existing hosts while a registration protocol is developed and deployed. It needs to be kept simple so that it is both quick and easy to deploy, and not become so "featureful" such that the effort involved in developing and deploying it is taking time away from the effort involved in developing and deploying a registration protocol. Thanks, Mark. >________________________________ > From: Oliver <oli...@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> >To: ipv6@ietf.org >Sent: Saturday, 20 October 2012 3:25 AM >Subject: Announcing Hashed SLND and other changes to >draft-smith-6man-mitigate-nd-cache-dos-slnd > >Link for convenience: http://tools.ietf.org/html/draft-smith-6man-mitigate-nd- >cache-dos-slnd-04 > >The following is a (non-exhaustive) overview of the changes: > >1) Described Hashed SLND > >2) Replaced TUSP with TUD > >3) Clarified required & optional behaviour. > >4) Expanded scope for SLND > >5) fixed up a few nits. > >Comment and feedback most appreciated. > >Kind Regards, >Oliver >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
