At Tue, 19 Aug 2014 15:10:39 -0300, Fernando Gont <[email protected]> wrote:
> > If so, one possible alternative would be to drop such ICMPv6 PTB > > unless the source IPv6 address is one of those reserved for such use > > (as defined in RFC 6052). > > Source of the ICMPv6 message? I was not really accurate - I should have said the destination address of the original IPv6 packet that triggered the ICMPv6 PTB. But in this specific case, the effect should be the same in practice, since the source of the ICMPv6 PTB is the translator box, which would use the destination of the original IPv6 packet as the source of the ICMPv6. > If so, I'd say that while that's certainly > better than the current situation, unless there's widespread deployment > of BCP38, an attacker could still forge an ICMPv6 with one of such > addresses and still perform the attack.. In your previous/other messages you emphasized that the attack cannot be prevented by BCP38, seemingly to back the conclusion that completely killing PTB<1280 is the best option. Bringing the point that BCP38 isn't widely deployed once you saw a scenario where it could be a measure makes me doubt the credibility of this discussion: if your goal was to convince people with your preferred solution (which itself is perfectly fine), I'd rather see the discussion that way from the beginning, than listing possible options and soliciting general "thoughts". But anyway, even the point with the deployability of BCP38 is not that important in this case. The key part is here: >> And, unless/until we heavily rely on such >> types of translators, this may be actually sufficient in practice, >> since in the vast majority of legitimate cases we should use different >> addresses than those special ones. If SIIT-type of translators aren't really deployed at least yet (which we all seem to agree on), dropping the offending ICMPv6 PTB except for these special addresses effectively works as dropping them unconditionally. It still works better than dropping all such ICMPv6 PTB for the unlikely case of having serious deployments of SIIT, in that we don't break existing practices (although they need to decide whether to keep using it at the cost of seeing the DoS discussed here). And, while the SIIT-kind of spec may have to be revised because of this issue, we can still allow experimental/serious deployment of it at their own risk. If and when such revision of the spec is completed and reasonably deployed, we can then consider killing ICMPv6 PTB<1280 completely. > I must say that I fail to see the need for generating IPv6 atomic > fragments 8packets with a frag header, which are not really fragmented). > See e.g. what we wrote in > <http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>. > > Thoughts? I personally have no problem with deprecating atomic fragments (which would also deprecate PTB<1280 naturally); I'm not relying on SIIT myself nor I have any incentive to defend it in general. So, if others are also happy with that I'll be too. But as this thread actually shows, a proposal of deprecating something can often be controversial since it can break some existing deployment, and it's basically impossible to prove there's no such deployment (and the acceptable deployment level to justify the deprecation is often a matter of opinion). Now that I've seen such controversy, I'd personally prefer more gradual path like the "alternative approach" I mentioned. -- JINMEI, Tatuya _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
