Subject: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jan 2013 13:48:37 -0300

Folks,

We have published a revision of our I-D entitled "Security Implications
of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers.

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt>.

Any comments will be very appreciated.

Thanks!

Best regards,
Fernando

-------- Original Message --------
From: - Fri Jan 11 13:40:47 2013
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for
draft-gont-6man-ipv6-smurf-amplifier-01.txt
Message-ID: <[email-masked]>
Date: Fri, 11 Jan 2013 08:40:12 -0800

A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Filename:	 draft-gont-6man-ipv6-smurf-amplifier
Revision:	 01
Title:		 Security Implications of IPv6 options of Type 10xxxxxx
Creation date:	 2013-01-11
WG ID:		 Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt
Status:
http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-smurf-amplifier-01

Abstract:
   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.

The IETF Secretariat

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Jan 2013 09:10:49 +0100

Fernando, et al,

> Any comments will be very appreciated.

isn't this attack covered already inRFC4443, section 5.2 bullet 5?

cheers,
Ole

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Jan 2013 16:13:28 -0300

Hi, Ole,

> isn't this attack covered already inRFC4443, section 5.2 bullet 5?

No. The following text in Section 4.2 of RFC 2460 overrides what's in
RFC 4443:

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

That's why RFC 2460 needs to be updated.

FWIW, all implementations I've tested so far behave as specified in RFC
2460, and hence can be leveraged as smurf amplifiers.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Jan 2013 11:12:08 +0100

> No. The following text in Section 4.2 of RFC 2460 overrides what's in

An earlier RFC can't "override" a later RFC. The later RFC wins.

> 2460, and hence can be leveraged as smurf amplifiers.

That's a different (and better IMHO) reason why publishing something new 
could be useful.

Simon

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Jan 2013 18:52:34 -0300

Hi, Ole,

>> isn't this attack covered already inRFC4443, section 5.2 bullet 5?

BTW, bullet "e)" in Section 2.4 (page 6) of RFC 4443 says:

       (e.3) A packet destined to an IPv6 multicast address.  (There are
             two exceptions to this rule: (1) the Packet Too Big Message
             (Section 3.2) to allow Path MTU discovery to work for IPv6
             multicast, and (2) the Parameter Problem Message, Code 2
             (Section 3.4) reporting an unrecognized IPv6 option (see
             Section 4.2 of [IPv6]) that has the Option Type highest-
             order two bits set to 10).

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Jan 2013 18:57:27 -0300

Hi, Simon,

> An earlier RFC can't "override" a later RFC. The later RFC wins.

I agree that my phrasing was sloppy (at best -- the combination of
English as non-native language + no sleep never helps). However, I'd say
that a "later" RFC that does not formally update an earlier RFC does not
override anything.

In any case, both RFC 2460 and RFC 4443 agree on this point. As I've
just noted to Ole, BTW, bullet "e)" in Section 2.4 (page 6) of RFC 4443
says:

So I should probably note this in the I-D, and add RFC4443 to the RFCs
that need to be updated.

Thoughts?

> That's a different (and better IMHO) reason why publishing something new

In this case, since the RFCs are in agreement, I'm not sure if it would
add anything to comment that "all popular implementations behave as
specified in this RFCs". But I could include such a note if deemed
appropriate.

Thoughts?

Thanks so much!

Best regards,