Re: [DNSOP] Suggestion for "any" - TCP only

Paul Vixie <paul@redbarn.org> Tue, 10 March 2015 00:35 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36D61A9089 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 17:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K_ZwCqTt_rQ9 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 17:35:10 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3520E1A8821 for <dnsop@ietf.org>; Mon, 9 Mar 2015 17:35:10 -0700 (PDT)
Received: from [172.31.9.78] (unknown [123.126.24.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B23CA184D9; Tue, 10 Mar 2015 00:35:08 +0000 (UTC)
Message-ID: <54FE3C36.9090808@redbarn.org>
Date: Tue, 10 Mar 2015 08:35:02 +0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>
References: <CAH1iCir+h+Kfj1q6JSqhGJ9ev0TQwRDSMci3APKCR=gJAW1phQ@mail.gmail.com> <alpine.LFD.2.10.1503082115040.2914@bofh.nohats.ca> <54FD1969.3070405@redbarn.org> <alpine.LFD.2.10.1503082359510.31060@bofh.nohats.ca> <54FD2F2F.7050704@redbarn.org> <alpine.LFD.2.10.1503090936560.13703@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1503090936560.13703@bofh.nohats.ca>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------070907080304050701000702"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/kgGLFnhpyNE0vJOrmbBk1BJNnu8>
Cc: dnsop <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Re: [DNSOP] Suggestion for "any" - TCP only
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 00:35:11 -0000


> Paul Wouters <mailto:paul@nohats.ca>
> Monday, March 09, 2015 10:02 PM
> On Sun, 8 Mar 2015, Paul Vixie wrote:
>
>>> So why are we proposing to ACL the ANY queries again?
>>
>> because people like me with dig-based diagnostic tools want to be able
>> to run ANY queries against our own servers, from our NOC/SOC.
>
> Fair enough.
>
>>> Cloudfare is not doing this for privacy reasons. So let's not kid
>>> ourselves.
>>
>> cloudflare's motives are their own affair. our motives, as a community,
>> for getting behind the cloudflare proposal, are what should concern us.
>
> But all the text you want to remove from the -00 points to why people in
> real life will deploy this, and you are stating that is wrong use of the
> draft. Your suggestion of removing the text won't change what people
> will actually use this draft for, which is to fight amplification
> attacks (and avoid needing to implement "difficult ANY code")

anyone who uses this draft to defend against amplification or reflection
is a fool, or else, was misled by some assertion made in the draft or on
this mailing list that blocking ANY (or other meta-queries) is an
effective defense against reflection/amplification. we have to stick a
pitchfork in the neck of that idea. or, if you prefer: that idea is a
criminal whose head should be on a pike outside the city wall.
>
> Another argument I've heard is about the privacy of a cache. If that's
> the goal of the draft, perhaps we should move it to dprive and make
> that explicit?

we don't have to move something to dprive just because it touches on
privacy. limiting surveillance opportunities by intermediaries is no one
working group's sole charge -- it's something all working groups must do.
>
> If we specifically want to address the ANY amplification,

we don't. this is not an amplification issue.

> ... If we look at the core issue, amplification based on
> spoofed source IPs,

amplification based on spoofed source IP's is not the core issue.

but we can go back and forth beating that dead meme another few dozen
times if you want.

-- 
Paul Vixie