IETF Logo Mail Archive

Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON)

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 22 August 2013 20:51 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CA311E8220 for <v6ops@ietfa.amsl.com>; Thu, 22 Aug 2013 13:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFjwoRMvLoRx for <v6ops@ietfa.amsl.com>; Thu, 22 Aug 2013 13:51:33 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBF11E81CD for <v6ops@ietf.org>; Thu, 22 Aug 2013 13:51:30 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r7MKpNFt013940; Thu, 22 Aug 2013 21:51:23 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r7MKpNFt013940
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1377204684; bh=1oyUKbxKNOit7OXhuS/BqZ4km9E=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UJEVJG2RCJO80UAPf0iOk2TrWAh2peQQqA93+LTKTwm618hIzeRAGGWYWud3+HXFy QweF9LLoMSoCtPLKyuwT1K89xd5pDYUxoggce//+j5ciU4jzmDRp7mAaZhLEgr5AcJ uR0sTOCCkga5iAnBBbs3oK2MqljayqN5JOHFg7WY=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id p7LLpN05445349843s ret-id none; Thu, 22 Aug 2013 21:51:24 +0100
Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r7MKpHVT024984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 21:51:18 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F144E0A-E918-4AAE-BB9A-02630968D953"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <52165DC0.7090406@scea.com>
Date: Thu, 22 Aug 2013 21:51:18 +0100
Message-ID: <EMEW3|aa8823c39ca54364e45099ae590c0046p7LLpN03tjc|ecs.soton.ac.uk|CFF483B5-E780-4D8F-B2B4-2F9AE19A4147@ecs.soton.ac.uk>
References: <52165DC0.7090406@scea.com> <CFF483B5-E780-4D8F-B2B4-2F9AE19A4147@ecs.soton.ac.uk>
To: Tom Perrine <tperrine@scea.com>
X-Mailer: Apple Mail (2.1508)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=p7LLpN054453498400; tid=p7LLpN05445349843s; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: r7MKpNFt013940
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: IETF v6ops list <v6ops@ietf.org>
Subject: Re: [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 20:51:35 -0000

On 22 Aug 2013, at 19:51, Tom Perrine <tperrine@scea.com> wrote:

> 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.)

There's lots of work within the IETF on this, e.g. take a look at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.

The sunset4 WG is also quite interesting.

I'm surprised an event like DEFCON presented something that old.

Tim

v2.23.0 | Report a Bug | By Email