Jinmei, On 08/20/2014 05:37 PM, 神明達哉 wrote: >> 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.
I never said that. And that certainly wasn't my line of reasoning. I emphasized that BCP38 doesn't block the attack, because BCP38 does block many/most of this sort of attack (e.g., attacks against TCP connections, etc.). Then, we came up with one possible way to mitigate this vulnerability and asked for comments. > 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". I asked for "thoughts" because I might have missed or overlooked something, or someone might come up with a better idea. Given options so far, I tried to analyze pros and cons. The one you suggested addresses only one of the two kinds of translators (if I understood correctly), and may still leave the door open in some scenarios. That's why I concluded that the one we originally offered still seemed like the best way to fix this. (i.e., me thinking out loud rather that anything else) >>> 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). FWIW, the "dropping" is by the end node... and if that really is an issue, then we're already in "trouble", because it turns out that at least some boxes (some FreeBSD versions, NetBSD, and some Mac OS versions, fail to produce atomic fragments in response to ICMPv6 PTB). > 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. It's really "deployment at someone *else's* risk". Because it's the folks that generate atomic fragments the ones paying the price (and not the SIIT boxes or deployments). > 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). What breaks what may vary from one case to another. For instance, relying on atomic fragments implies that you rely on: 1) Both ICMPv4 and ICMPv6 messages not being filtered 2) IPv6 fragments not being filtered 3) Nodes reacting to ICMPv6 PTB<1280 Both 1 through 3 vary from one environment to another... but I'm of the idea that the lest you rely on them, the better. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
