Re: [DNSOP] Re: draft-ietf-dnsop-reflectors-are-evil-05.txt

Edward Lewis <Ed.Lewis@neustar.biz> Thu, 13 December 2007 17:54 UTC

Return-path: <dnsop-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2sGE-0005PN-Fn; Thu, 13 Dec 2007 12:54:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2sGC-0005M6-Vu for dnsop@ietf.org; Thu, 13 Dec 2007 12:54:12 -0500
Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2sGC-0003YR-GI for dnsop@ietf.org; Thu, 13 Dec 2007 12:54:12 -0500
Received: from [10.31.32.123] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lBDHs1gE060570; Thu, 13 Dec 2007 12:54:01 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240801c3871ddd0a9b@[10.31.32.123]>
In-Reply-To: <Pine.LNX.4.44.0712131126480.27223-100000@citation2.av8.net>
References: <Pine.LNX.4.44.0712131126480.27223-100000@citation2.av8.net>
Date: Thu, 13 Dec 2007 12:54:00 -0500
To: IETF DNSOP WG <dnsop@ietf.org>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: [DNSOP] Re: draft-ietf-dnsop-reflectors-are-evil-05.txt
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: ed.lewis@neustar.biz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Errors-To: dnsop-bounces@ietf.org

I'd like to direct a question to the chairs - would you summarize the 
open IESG discuss issues with the current document?  In this mail 
I'll allude to some of what I guess are the open discuss items.

Looking at the tracker there are discusses against -04 and a note 
that a new version is needed.  We have a -05 now, I suppose that 
qualifies as the new version.

Even though I am not an enthusiast of the notion that the attacks 
reported in spring 2006 incriminate open recursive resolvers, I think 
the draft should be published as it is and that we free this mailing 
list of any more arguments on the topic.

The document only recommends that name server code should be shipped 
with the open recursive configuration in the "off" position.  It does 
not say that operating an open recursive resolver is evil, despite 
the the file name.

Recommending that an operator attempt to scope the source of requests 
is harmless to those that want a wide open scope.  A recommendation 
of a scooping based on source IP address is not a client 
authentication vulnerability (as in it is trivial to spoof the source 
field of UDP) but is a reflection or a widely followed practice in 
operations.  Regardless of the IETF's notion of security, operators 
have their own rules of thumb and source IP address ACLs are part of 
that.

I can live with the details of the attacks, perhaps some find the 
prose confusing and I am sympathetic to calls to shore it up.  But I 
think that it really isn't crucial as the recommendations section is 
quite distinct from it.

There is one line in the -05 which I find to be the "meat."

"By default, nameservers SHOULD NOT offer recursive service to 
external networks."

Note the "by default."  If that were not present, I would object to 
the document.  To me, the statement is safe because there is no 
penalty to operating in any manner that is not the "default" way.  No 
justification is needed to diverge from "default."  So saying that 
the default is to not be an open recursive server is acceptable to me.

PS - The other comment in the discuss items - removing the 
possibility of amplification.  That can be done, but the cure is 
worse than the disease.  We can expand all queries to be the maximum 
acceptable response size (512 or to the size indicated via EDNS0) 
with padding of the queries.  That removes the incentive to use the 
recursive server as a reflector because you can then just have the 
botnet directly target the victim, probably with more aggregate 
bandwidth.  (Botnets could do that now, hit a victim with overstuffed 
DNS queries or falsified answers for that matter, thanks to UDP's 
fire and forget paradigm.)  For legitimate DNS, it would be a 
bandwidth waste.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop