Hi Karl, Thanks very much for your feedback.
----- Original Message ----- > From: Karl Auer <ka...@biplane.com.au> > To: ipv6@ietf.org > Cc: > Sent: Saturday, 13 October 2012 12:25 PM > Subject: Re: Fw: New Version Notification for > draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt > > On Fri, 2012-10-12 at 17:57 -0700, Mark ZZZ Smith wrote: >> Here's a new version of my stateless neighbor discovery draft. Changes: > > This para seems a little harder to understand than it should be: > > "A default route should never be used to define a trusted > packet source prefix. If a router's operator wishes to > trust all packet sources, they should specify ::/0 as a > configured trusted prefix." > > It seems to be saying "never use a default route to define a trusted > packet source prefix. If a router's operator wishes to trust all packet > sources, they should use a default route"! > I can see how that could be misinterpreted, although ::/0 is really only the default when it is used as routing information. I'll try to reword this text to make it a bit clearer that ::/0 is intended to be an "all IPv6 addresses" prefix added to the configured source prefix list if all sources are to be trusted. > Because there are no ND cache entries for a packet except at the last > router in its journey, there is no way to delegate the problem upstream. > It would be nice if, once a router had decided to start rate limiting NS > from a prefix, it could pass that info upstream to have the upstream > router rate limit it instead (or as well). I appreciate that your > mechanism is not designed to do this, but I thought I'd mention it. > I like the idea of that, although the hard part is how to avoid creating per destination address, or per source address or source prefix state to do it, in either the router that is the target of the DoS, or the upstream router(s) (e.g. per-source address backhole routes). It seems to me that any state that is created that is created to store or created related to IPv6 addresses is where address related DoS opportunities are created. I've though about this idea a little bit for the last few days, and can't see how you wouldn't create further address related state that could be DoS exploited in either the device that is the target of the DoS, or the upstream device. One perspective on my proposal might be that it is in effect pushing most of the functions that ND performs that use state back onto hosts that originate the traffic in the first place, which results in that state being distributed across those hosts, rather than being concentrated on the directly attached router. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
