Re: [v6ops] NAT64/DNS64 and DNSSEC

Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Wed, 29 July 2015 10:06 UTC

Return-Path: <Ondrej.Caletka@cesnet.cz>
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 36F241A01FC for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2015 03:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level:
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 zhhidEfvxYoz for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2015 03:06:17 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284891A0162 for <v6ops@ietf.org>; Wed, 29 Jul 2015 03:06:16 -0700 (PDT)
Received: from [IPv6:2001:718:1:6::134:196] (oskarpc.cesnet.cz [IPv6:2001:718:1:6::134:196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id F2961ED393E for <v6ops@ietf.org>; Wed, 29 Jul 2015 12:06:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1438164374; bh=feETV24G+bkDpULWjqoGNfv4bffxNuucjYeu4NddR7s=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=rB21h7I8QEYR2j/vRZ9K2rMdtl4XjU6B4DtwvMX/vaqH4rXgpkzJ+9yG+2nzpb8/z l63IsaFacaprvJVB5F71Je6zH08RQW3850znUl0yf6zkWMZZJwodpcCul7eB9e/6Wd HNrNxuA/l3PmxwwRiZgxN2ZkjDF5r3O+yh7f6pZY=
To: v6ops@ietf.org
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>
From: =?UTF-8?Q?Ond=c5=99ej_Caletka?= <Ondrej.Caletka@cesnet.cz>
X-Enigmail-Draft-Status: N1110
Message-ID: <55B8A596.80600@cesnet.cz>
Date: Wed, 29 Jul 2015 12:06:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060702090601030909060509"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/bJ_GDL9Vj8n-FDy847iqHuVwywE>
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: Wed, 29 Jul 2015 10:06:19 -0000

Hello,

Dne 28.7.2015 v 21:58 holger.metschulat@telekom.de napsal(a):
> 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?

That is why there is a requirement in RFC7050 Section 3.1. to validate
network-specific NAT64 prefix using reverse and forward DNSSEC secured
queries. The only problem is that there is no way so far how to seed the
list of trusted NSP domains. Instead of asking users "Do you want to
trust the network prefix dns64.example.org?", there could probably be
some matching with domain name received by other means like DHCP or DNSSL.

Of course, using the Well-known prefix is on the safe side, and should
be IMO used wherever applicable.

Cheers,
Ondřej Caletka