Subject: New IETF I-D on IPv6 smurf amplifiers

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Dec 2011 08:11:03 -0300

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-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 21 Dec 2011 17:56:27 +0100

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-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: mardi 20 décembre 2011 12:11
> To: [email-masked]
> Subject: New IETF I-D on IPv6 smurf amplifiers
> 
> Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Dec 2011 14:31:53 -0300

Hi, Eric,

Thanks so much for your comments. Please find my responses inline...

On 12/21/2011 01:56 PM, Eric Vyncke (evyncke) wrote:
> 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

Note that this limit might kill other stuff -- just blindly limiting
ICMPv6 traffic might e.g. introduce PMTUD blackholes.

> 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 v6 specs carefully eliminate other potential smurf amplifiers. --
But this one was "left in". Getting an error from multiple destination
hosts doesn't look like a good idea. -- but I'll let others weigh in...

Thanks,