IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 02 August 2014 20:23 UTC

Return-Path: <mcr@sandelman.ca>
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 029111B2986 for <sunset4@ietfa.amsl.com>; Sat, 2 Aug 2014 13:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 xwsd3oqll-03 for <sunset4@ietfa.amsl.com>; Sat, 2 Aug 2014 13:23:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C71B2983 for <sunset4@ietf.org>; Sat, 2 Aug 2014 13:23:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 199D320012; Sat, 2 Aug 2014 16:26:09 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 80867638D9; Sat, 2 Aug 2014 16:23:52 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68CF5638D7; Sat, 2 Aug 2014 16:23:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Simon Perreault <sperreault@jive.com>
In-Reply-To: <53D6559B.2090300@jive.com>
References: <11190.1406240244@sandelman.ca> <C12A07EA-E27A-4EAF-A9DE-536FF22A0395@cisco.com> <3B647D53-0E22-43C3-892D-319C9109248C@nominum.com> <53D6559B.2090300@jive.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sat, 02 Aug 2014 16:23:52 -0400
Message-ID: <19625.1407011032@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/sjjzLwVXBHGNK07HJu4oF_PEGhs
Cc: 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: Sat, 02 Aug 2014 20:23:56 -0000

Simon Perreault <sperreault@jive.com> wrote:
    >> 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.

    > Dan didn't say "broken", he said "attacker-controlled", possibly (my
    > guess) thinking of the infamous "SLAAC attack" [*]. Happy eyeballs is
    > useless here.

    > The new vulnerability introduced by No-IPv4 over RA is the "drive by"
    > nature of the attack: contrary to the SLAAC attack, the attacker
    > doesn't need to remain on the network. It can shut off the victim's
    > IPv4 access quickly then drive away.

If the No-IPv4 is defined to mean: "reduce the frequency of your DISCOVER"
it seems that the attacker has to retransmit regularly...  It seems to me
that if the machine has *no* network connectivity at all yet (no IPv6
either, which the IPv6 process listening to the No-IPV4 message would know),
then the node should be skeptical about the NoIP4 flag anyway.

My understanding of the goal is to reduce the amount of *broadcast* DHCPv4
traffic that cloggs up some networks' infrastructure, because nodes that
don't get IPv4, ask more and more often as they can't find it.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email