Re: [v6ops] NAT64/DNS64 and DNSSEC

Ca By <cb.list6@gmail.com> Tue, 28 July 2015 21:49 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843AB1B3249 for <v6ops@ietfa.amsl.com>; Tue, 28 Jul 2015 14:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level:
X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-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 ugn2TxexKbuX for <v6ops@ietfa.amsl.com>; Tue, 28 Jul 2015 14:49:49 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA151B3248 for <v6ops@ietf.org>; Tue, 28 Jul 2015 14:49:49 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so175455495wib.0 for <v6ops@ietf.org>; Tue, 28 Jul 2015 14:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/zwvDhvg6tCPh0XdQqx2y+rFPUmdRYeZsRDen3w+GOk=; b=eq/dkO9J8a9vxde+CqdGacJCAUSt1ZOCE407BXC7fSwWXfdWeobFWWN6PyQaFC8RmR F7GbIfF9riBP4QKlDN1GC9eQbS5sspDaKXdUEqDKEAxYCJH1Yz3FikMFeCUmdwLxDnoQ QfuADOqriu8FmsnA40YD1dS/A8S9x9HEikdOD1cZ37SXIQQNYUM6j9CfUH9XEteJMoir gCFPxSACIa9ilTPVfyBAe6wHZas1n3VhO5IOtcvBcJznp2rYr+YsezRfFWMhoL0vLgxt 2+pQdMcABdHMBP5nTjWctZSo4oA4p6Q+1Uo6sFK7hpc7P0MiJLjclg0xh+nknc8ZI6VD AfrQ==
MIME-Version: 1.0
X-Received: by 10.180.109.136 with SMTP id hs8mr11020884wib.73.1438120188031; Tue, 28 Jul 2015 14:49:48 -0700 (PDT)
Received: by 10.194.191.232 with HTTP; Tue, 28 Jul 2015 14:49:47 -0700 (PDT)
In-Reply-To: <m1ZKCg7-0000CdC@stereo.hq.phicoh.net>
References: <alpine.DEB.2.02.1507230910190.11810@uplift.swm.pp.se> <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <ED7E283A-0430-4D4E-87A6-ED9FD8DFC6F4@nominum.com> <m1ZIYIw-0000EuC@stereo.hq.phicoh.net> <CAAedzxrWExsiyh4hhsfJTufuRVM_67f2tGWkHCLc9kiduTU0hg@mail.gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> <m1ZKCg7-0000CdC@stereo.hq.phicoh.net>
Date: Tue, 28 Jul 2015 14:49:47 -0700
Message-ID: <CAD6AjGQPax+pdK5eUZuQmoSb8ZJgR37Hdj5o1P_mxaoudc4WtA@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Content-Type: multipart/alternative; boundary=e89a8f234557f3b86b051bf672bd
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/CpyfXQHmyMH1ySAd6rmyuf6_Iic>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 28 Jul 2015 21:49:51 -0000

On Tuesday, July 28, 2015, Philip Homburg <pch-v6ops-3@u-1.phicoh.com>;
wrote:

> In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote:
> > but isn't there a gap that when performing the RFC7050 64pref
> > detection by querying ipv6only.arpa, an attacker can spoof this
> > answer (DNSSEC won't work here, for example, the attacker - when
> > between the client and the DNS - can return for example
> > 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the
> > attacker)) and then attract all IPv4 traffic from the victim?
> >
> > Nevertheless, an answer to the proliferation of DNSSEC and at the
> > same time increasing usage of DNS64/NAT has to be found, not to
> > stop the success of one or the other.
>
> Yes, that seems to be a very tricky problem.
>
> One option is perform local translation only for 64:ff9b::/96. This would
> force operators to use the well known prefix, but it has to advantage that
> the prefix can be filtered at the border of each network. And an attacker
> will be quite visible trying to get this traffic by manipulating routing
> protocols.
>
> A second approach is for the network to signal that there is no IPv4
> present.
> For example, by not including a default route in DHCPv4 or otherwise
> signaling
> in DHCPv4 that there is no IPv4.
>
> In this case, if there is a valid IPv4 config, the library can refuse to
> perform the synthesis. This would leave all dual stack networks unaffected.
>
> Performing the AAAA lookup on ipv4only.arpa over tcp would require
> the attacker to be on the path to the resolver.
>
> An alternative to requiring 64:ff9b::/96, would be to insist that the
> NAT64 gateway and the DNS64 are in the same /48. That would require an
> attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets
> are off.
>
> Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious
> solution is that if those sites care about security, they should add a
> AAAA.
>
>
+1

This is just another way that ipv4 is too broken to use and will not be
fixed.

BCP = use native ipv6


> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/v6ops
>