Hi, Jinmei, On 08/19/2014 02:58 PM, 神明達哉 wrote: >> As noted in the I-D, the mitigations seem to be: >> >> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 >> PTB, or, >> >> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU >> smaller than 1280. >> >> Thoughts? > > In my general understanding, ICMPv6 PTB with the MTU < 1280 could be > only (at least in practice) used for the "stateless" type of IPv4/v6 > translators so that the IPv6-only host can give the translator a hint > for the 16-bit IPv4 header ID value. Am I correct?
Yes. (That's the theory, at least. Me, I'd say that the host is really in no better position than the translator to pick a Frag ID... actually, it's in a much worse position). > 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? 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.. > Then we can at least reduce the problem to > source address spoofing. 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. 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? Thanks! Best regards, -- 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
