IETF Logo Mail Archive

Re: [sunset4] to summarize Lorzeno's "drive-by" attack on draft-ietf-sunset4-noipv4

Ted Lemon <ted.lemon@nominum.com> Sun, 27 July 2014 21:46 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43C1A0368 for <sunset4@ietfa.amsl.com>; Sun, 27 Jul 2014 14:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMHnywemhN7p for <sunset4@ietfa.amsl.com>; Sun, 27 Jul 2014 14:46:25 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169211A0366 for <sunset4@ietf.org>; Sun, 27 Jul 2014 14:46:24 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A07491B877F for <sunset4@ietf.org>; Sun, 27 Jul 2014 14:46:24 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8EE8D190052; Sun, 27 Jul 2014 14:46:24 -0700 (PDT)
Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 27 Jul 2014 14:46:24 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <C12A07EA-E27A-4EAF-A9DE-536FF22A0395@cisco.com>
Date: Sun, 27 Jul 2014 17:45:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <3B647D53-0E22-43C3-892D-319C9109248C@nominum.com>
References: <11190.1406240244@sandelman.ca> <C12A07EA-E27A-4EAF-A9DE-536FF22A0395@cisco.com>
To: Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/oi382IBWhCfphrUURZcuvZC7cgg
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, sunset4@ietf.org
Subject: Re: [sunset4] to summarize Lorzeno's "drive-by" attack on draft-ietf-sunset4-noipv4
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jul 2014 21:46:28 -0000

On Jul 25, 2014, at 9:05 PM, Dan Wing <dwing@cisco.com> wrote:
> Specifically, the network has to allow an arbitrary host to send an IPv6 RA.  Doesn't that open the network to a pile of attacks, including an attacker-controlled IPv6 DNS server (RFC6106) and attacker-controlled IPv6 default route?

It does, but if the network provides DHCP service and the attacker either fails to answer faster, or is prevented from acting as a DHCP server, then happy eyeballs will take care of the broken IPv6 service.   If your portable device is using any protocols that are susceptible to MiTM attacks, you shouldn't be connecting it to networks anyway, so we don't have to care about snooping, right? :)

So compare that to no-IPv4, where if this is propagated using RA or DHCPv6, it's possible to actually shut off the IPv4 connection and prevent the user from connecting over the IPv4 internet.

v2.23.0 | Report a Bug | By Email