My usual recommendations about this issue (and the related packet-too-big sent to a mcast group) are quite commonly accepted and are described in your I-D in 2.2: - RPF for all traffic - rate limit per node the ICMP generation - rate limit per router the ICMP traffic to a 100-1000 pps
I would rather be reluctant to change RFC 2460/4443 even if there appears to currently have no valid use of option type 10xxxxxx because who knows in the future? And getting an error message is quite important. The above counter-measures also mitigate the risk of reflection attacks and not only smurf-like amplification attacks. So, this should be the only recommended approach (i.e. remove 2.1 from your I-D) Hope it helps -éric > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Fernando Gont > Sent: mardi 20 décembre 2011 12:11 > To: [email protected] > Subject: New IETF I-D on IPv6 smurf amplifiers > > Folks, > > We have published a new IETF I-D on "IPv6 smurf amplifiers". The I-D is > available at: > <http://tools.ietf.org/id/draft-gont-6man-ipv6-smurf-amplifier-00.txt>. > > This may be an issue when BC38 is not deployed, or when the BCP38 > implementation is buggy (yes, there have been instances of this). > > Note: This vector can also be exploited with normal link-local multicast > addresses, but for obvious reasons it becomes a more important issue > with non-local multicast. > > Abstract: > ---- cut here ---- > When an IPv6 node processing an IPv6 packet does not support an IPv6 > option whose two-highest-order bits of the Option Type are '10', it > is required to respond with an ICMPv6 Parameter Problem error > message, even if the Destination Address of the packet was a > multicast address. This feature provides an amplification vector, > opening the door to an IPv6 version of the 'Smurf' Denial-of-Service > (DoS) attack found in IPv4 networks. This document discusses the > security implications of the aforementioned options, and formally > updates RFC 2460 such that this attack vector is eliminated. > Additionally, it describes a number of operational mitigations that > could be deployed against this attack vector. > ---- cut here ---- > > Any feedback will be welcome. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
