Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

Paul Vixie <paul@redbarn.org> Fri, 16 October 2015 18:31 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 671A11A8A46 for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 11:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D_1a692iSDGR for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 11:31:00 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A581A8A42 for <dnsop@ietf.org>; Fri, 16 Oct 2015 11:31:00 -0700 (PDT)
Received: from linux-rfx1.localnet (unknown [IPv6:2001:559:8000:cb:958d:c6fd:152:3050]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 69CC913AEB; Fri, 16 Oct 2015 18:30:59 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Date: Fri, 16 Oct 2015 18:30:52 +0000
Message-ID: <1653724.UdtLHTI650@linux-rfx1>
Organization: Vixie Freehold
User-Agent: KMail/4.14.10 (Linux/4.2.1-1-desktop; KDE/4.14.12; x86_64; ; )
In-Reply-To: <BCE894DC-01B6-42C4-9589-1C19CA395250@hopcount.ca>
References: <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org> <A7B11A56-A66F-4E13-9675-56344E25C403@vpnc.org> <BCE894DC-01B6-42C4-9589-1C19CA395250@hopcount.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1498153.81tMoSAdrl"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/SarepNVTipVyiQRZYtBNH4NaYPI>
Cc: Darcy Kevin <kevin.darcy@fcagroup.com>
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 16 Oct 2015 18:31:02 -0000

On Friday, October 16, 2015 13:58:00 Joe Abley wrote:
> On 16 Oct 2015, at 13:15, Paul Hoffman wrote:
> > On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
> >> Let's see, millions of full-service resolvers, times the packet-count
> >> differential between UDP and TCP, times the average reload/restart
> >> frequency of those full-service resolvers per day/week/month. Can't a
> >> case be made from sheer volume?
> > 
> > The root operators have shown no concern about legitimate resolvers
> > asking a lot more queries.

i am a root operator and i reject your characterization of my position.

i don't want tcp tried first, ever. i understand that tcp would be tried 
first, for new-fangled clients who want to try to negotiate persistent tcp. 
but that should not include the priming query, because root name servers are 
expected to have a large number of rdns servers to serve, and tcpcb's will 
always be finite.

> > Given that using TCP for priming helps
> > mitigate an injection attack,

given that tcp is often blocked by firewalls since udp mostly just works and 
has always been tried first, i think that leaning on tcp to help with a 
priming injection attack has a low success likelihood. let's get the injection 
attack solved in other ways, for example, using dns cookies.

-- 
Paul