Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice?

Mark Townsley <mark@townsley.net> Tue, 09 July 2013 14:49 UTC

Return-Path: <mark@townsley.net>
X-Original-To: dns-dir@ietfa.amsl.com
Delivered-To: dns-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230FF11E80EE for <dns-dir@ietfa.amsl.com>; Tue, 9 Jul 2013 07:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 wbsVVSH37LpI for <dns-dir@ietfa.amsl.com>; Tue, 9 Jul 2013 07:49:42 -0700 (PDT)
Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id BB4C221F9EC3 for <dns-dir@ietf.org>; Tue, 9 Jul 2013 07:49:41 -0700 (PDT)
Received: by mail-ea0-f182.google.com with SMTP id d10so3850103eaj.13 for <dns-dir@ietf.org>; Tue, 09 Jul 2013 07:49:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DUg4ssAKNa1z0ZTeLtWUsVMZqoFoTunV+HrvFn2JfnM=; b=Uia5aT+OdadTGcRQZOdbE+bjpFhdQ22iNHEWxjIXcnX5Tlu74cisOmIMcsytj1MGVq VcE7JVnOOB+dhr506uYqXIix1YZUHTbpcEH1eXA7114NS8LU55RmXcghRgtNd8dU3GiC 6mb5ekLLpZwgK0FMo2e4iezoVU9YL47jUMpJ8/lckMWkUxh9bCauZ72uomlNgTTNcYB9 Rv5atbtjaTHt1/Net1vE+biuRsJ4tr0I4yHqUkpqvd47UnsbOQB6pasWbq7L07marhy+ ScsJspVdEAL/wblke1895/9C46lv/Mrh5KLNRe0HPSkl9yYoxNtXmMlE8L56Y+rugFhy DN8Q==
X-Received: by 10.14.122.201 with SMTP id t49mr31330712eeh.26.1373381380625; Tue, 09 Jul 2013 07:49:40 -0700 (PDT)
Received: from ?IPv6:2001:420:44f0:1004:ec3e:8be2:7015:16d6? ([2001:420:44f0:1004:ec3e:8be2:7015:16d6]) by mx.google.com with ESMTPSA id m1sm51492239eex.17.2013.07.09.07.49.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 07:49:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com>
Date: Tue, 09 Jul 2013 16:49:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DAE62F3-FA49-4F17-8E1B-6223ABE27673@townsley.net>
References: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQkqCDDMcHMaccwMs/I3cKtbV1TCDx4yMlVIx0/YfJzCn55Bo2IKtSW78HClpDRym6NSkf1H
Cc: "dns-dir@ietf.org" <dns-dir@ietf.org>
Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice?
X-BeenThere: dns-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-dir>
List-Post: <mailto:dns-dir@ietf.org>
List-Help: <mailto:dns-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 14:49:47 -0000

On Jul 9, 2013, at 4:17 PM, Ted Lemon wrote:

> On Jul 9, 2013, at 9:50 AM, Mark Townsley <mark@townsley.net> wrote:
>> Safe in what sense? Are there security dangers in it?
> 
> It certainly breaks DNSSEC.  

Well, if the request isn't being responded to at all, I suppose that goes without saying.

>  Silently ignoring queries on a name can lead to long timeouts.

Even if only for AAAA requests with a host that (presumably) doesn't even have an IPv6 address configured (because by definition in the paper it is supposed to be connected to an IPv4 only network)? 

>   They were going to return NXDOMAIN, which would have been really exciting, but they at least agreed to take that out.
> 
>> I can state a lot of reasons why I don't *like* it:
>> 
>> - Please just deploy IPv6 instead
>> - Users that want to get around this, can (8.8.8.8)
>> - Inconsistency in DNS is hard to diagnose, troubleshoot, etc....
> 
> Actually I think they want to also intercept DNS queries at the firewall, so querying against google's name service wouldn't work.

lovely.

> 
>> That said, 6to4 and Teredo are as rampant as they are broken. Perhaps the focus should be on ridding these from codebases entirely rather than pussyfooting around about it as we have in the past. 
> 
> Breaking 6to4 and Teredo at the enterprise firewall is pretty easy.  

Yes, but that also leads to timeouts. 

>  This is a document about how to run enterprise networks where you aren't doing IPv6.   Personally I think it's bad because it encourages enterprises to postpone upgrading to IPv6, when in fact enterprises are one of the easiest places in the world to do IPv6, and there are substantial benefits to switching.   But my main concern about this document is that it will be read as the IETF generally supporting the techniques it describes, even though the introduction says it's specifically for corporate environments.

I completely agree that we shouldn't be giving advice on how to run IPv4-only and IPv6-hostile networks - on philosophical grounds. 

But, you asked if this was "safe", and its in an "opsec" WG. I'm trying to understand what's unsafe here, what the target is for the doc, etc.

> 
> So if there is something about the paragraph I quoted that would cause genuine breakage, but that I have missed, that's what I'm hoping someone will tell me.   The paragraph gives me an uneasy feeling, but having gotten rid of the NXDOMAIN bug, there is nothing specific that I can point to, with my limited operational experience, as being clearly broken.

Yeah, I'm not seeing what this breaks, aside of IPv6. But, that seems to be the intent....

- Mark

>