Re: [DNSOP] Should root-servers.net be signed

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 19 March 2010 15:40 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF1D3A6A89 for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 08:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.546
X-Spam-Level:
X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03PCqT4uDnbO for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 08:40:58 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2EE203A6A64 for <dnsop@ietf.org>; Fri, 19 Mar 2010 08:40:58 -0700 (PDT)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2JFfAS3029822; Fri, 19 Mar 2010 08:41:10 -0700 (PDT)
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost><0E169711-92DC-4AEA-AA81-718F298D1645@hopcount.ca><alpine.LSU.2.00.1003081614480.1897@hermes-2.csi.cam.ac.uk><A2D7C5EE-9937-4529-A28F-23296485A8B2@hopcount.ca><43FC3F50679F458A869F99D72ECD1237@localhost><20100309151726.GC5108@dul1mcmlarson-l1-2.local> <6C56581E-D4F4-4A49-A3B4-CB7F1CF42E29@icsi.berkeley.edu> <183BEF785A9844F186558A87848A6698@localhost> <061F30F4-E0EE-40E6-A54D-246D9E9A9D77@ICSI.Berkeley.EDU> <6D6F580F8CFB4DB5AB32566FB608088D@localhost> <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU> <03CF4A3B5B374C4C858DEEB2D66C0702@localhost>
In-Reply-To: <03CF4A3B5B374C4C858DEEB2D66C0702@localhost>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Priority: 3
Content-Type: text/plain; charset="us-ascii"
Message-Id: <AA116C2A-CCFC-4177-A43A-B3AA066B3C3C@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Fri, 19 Mar 2010 08:41:10 -0700
To: George Barwood <george.barwood@blueyonder.co.uk>
X-Mailer: Apple Mail (2.1077)
Cc: dnsop@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [DNSOP] Should root-servers.net be signed
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Mar 2010 15:40:59 -0000

On Mar 19, 2010, at 8:32 AM, George Barwood wrote:

> 
>>> There are advantages besides messages being lost.
>>> It also prevents spoofing of fragments, and limits amplification attacks.
> 
>> It doesn't limit amplification attacks by much if at all
> 
> It cuts the response from 4K to 1.5K, and I think fragmentation that contributes
> to these attacks being damaging.

All I need to do is find a set of open resolvers which don't have such limits to do juuust fine.  

And amplification attacks are overrated anyway:  DOS burns your bots, and most of your bots can't send spoofed packets anyway these days.  

So if you are going to burn your bots, do application level: its amazing how much damage SSL setups can do to your load if you don't have dedicated crypto hardware.

>> and spoofing of fragments is not likely to be happening in large responses, because large .responses will almost invariably be due to DNSSEC.
> 
> Resolvers may set DO=1 but not validate everything ( or even anything ).
> 
> Taking .SE as an example, by sending an open resolver that doesn't/cannot randomize ports the query [ NS SE ] ,
> if the .SE servers don't conceal the IP ID, only 1 spoof packet is needed, and poisoning is easy and certain, is it not?
> 
> Note: the .SE example does not truncate, it's very unusual for a response to be truncated with a EDNS @ 1450.

Actually, this doesn't apply, since the reason why ns.se is 2700B is all the RRSIGs in the additional section, which are after the A and AAAA records.  So spoofing this part of the datagrams is pointless anyway, since that only has meaning if DNSSEC validation IS performed.


I really don't want to enshrine "Fragments don't work at ALL" into the infrastructure, rather I want "fragments are unreliable, so you need to detect if its YOUR side thats f-ing up and take action", thus it should be the onus on the resolver, not the authorities, to detect when this occurs and do something about it.