[v6ops] IPv6 transition technologies vs MITM (DEFCON)

Tom Perrine <tperrine@scea.com> Thu, 22 August 2013 18:51 UTC

Return-Path: <tperrine@scea.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DFBE011E81F5 for <v6ops@ietfa.amsl.com>; Thu, 22 Aug 2013 11:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OPil2jS2ghfU for <v6ops@ietfa.amsl.com>; Thu, 22 Aug 2013 11:51:46 -0700 (PDT)
Received: from ironport04a.scea.com (ironport04a.scea.com []) by ietfa.amsl.com (Postfix) with ESMTP id F3A9411E81FB for <v6ops@ietf.org>; Thu, 22 Aug 2013 11:51:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,935,1367996400"; d="scan'208";a="1979120"
Received: from inbetweener02.scea.com ([]) by ironport04a.scea.com with ESMTP; 22 Aug 2013 11:51:44 -0700
Received: from sd-tperrine-mpl.local (unknown []) by inbetweener02.scea.com (Postfix) with ESMTP id 563C0B811A for <v6ops@ietf.org>; Thu, 22 Aug 2013 11:51:44 -0700 (PDT)
Message-ID: <52165DC0.7090406@scea.com>
Date: Thu, 22 Aug 2013 11:51:44 -0700
From: Tom Perrine <tperrine@scea.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: IETF v6ops list <v6ops@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [v6ops] IPv6 transition technologies vs MITM (DEFCON)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2013 18:51:52 -0000

There's been a fair amount of debate on the list about the merits of using the transition technologies vs an aggressive
move to native IPv6 (usually dual-stack). We keep coming back to (as we have for 10+ years) to finding business reasons
to transition.

In parallel, there's been a goodly amount of poking around IPv6, "the real world" and those transition technologies.

The MITM attack demonstrated at DEFCON this year was nothing new. While it was widely covered as an "IPv6 security
flaw", it was really taking advantage of the well-known "RA problem" and the behavior of an IPv6-capable node on a
nominally IPv4-only network.

Frankly, while it was a nice "one click" automation of an already-recognized exploit, there wasn't really anything new.

But, what I'm seeing is that no one is talking about how the transition strategies will not address this attack at all,
at least as far as I can tell. They all seem to seek to leave (allegedly) IPv4-only nodes in place and work at one or
more hops away from those nodes. This ignores that so many nodes really aren't IPv4-only. They are really dual-stack
nodes that are waiting for the IPv6 configuration to be completed. And you can complete that configuration, or your
attacker will!

I see two ways to mitigate this attack:  turn off IPv6 on all modern OSes, or fully deploy IPv6.  Guess which one I
don't want to see advocated :-)

Am I missing something, or is this one more point to add to the "deploy IPv6 now, deploy native, skip the transition
technologies" ?  (I'm including dual-stack in the native strategy.)