Re: [DNSOP] Should be signed

"George Barwood" <> Sat, 20 March 2010 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F7B23A6886 for <>; Sat, 20 Mar 2010 01:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.569
X-Spam-Level: ***
X-Spam-Status: No, score=3.569 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2xCTEurqSsjD for <>; Sat, 20 Mar 2010 01:50:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 34EF43A687B for <>; Sat, 20 Mar 2010 01:50:37 -0700 (PDT)
Received: from [] (helo=anti-virus01-09) by with smtp (Exim 4.52) id 1NsuOM-0005Gk-Jz; Sat, 20 Mar 2010 08:50:46 +0000
Received: from [] (helo=GeorgeLaptop) by with esmtpa (Exim 4.52) id 1NsuOL-0005EK-QL; Sat, 20 Mar 2010 08:50:45 +0000
Message-ID: <A919A34B654541468475464F0C794962@localhost>
From: George Barwood <>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost><><><><43FC3F50679F458A869F99D72ECD1237@localhost><20100309151726.GC5108@dul1mcmlarson-l1-2.local> <> <183BEF785A9844F186558A87848A6698@localhost> <061F30F4-E0EE-40E6-A54D-246D9E9A9D77@ICSI.Berkeley.EDU> <6D6F580F8CFB4DB5AB32566FB608088D@localhost> <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU> <03CF4A3B5B374C4C858DEEB2D66C0702@localhost> <AA116C2A-CCFC-4177-A43A-B3AA066B3C3C@ICSI.Berkeley.EDU> <7F872C0CAA544F9480BF49438AAFA3BF@localhost> <68584293-648A-4F4E-8731-785E8F4D38B7@ICSI.Berkeley.EDU> <662061674DB34DB395F519F52B0C4C35@localhost> <9B17C765-036B-40BD-B05A-E1A3E4582D91@ICSI.Berkeley.EDU>
Date: Sat, 20 Mar 2010 08:50:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc:, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [DNSOP] Should be signed
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Mar 2010 08:50:38 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
To: "George Barwood" <>
Cc: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>; <>
Sent: Friday, March 19, 2010 7:48 PM
Subject: Re: [DNSOP] Should be signed

>On Mar 19, 2010, at 12:01 PM, George Barwood wrote:
>> Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?\

>No:  I agree it is the proper default for the TLD authorities and roots, but for everything else, the higher value should be what the resolver requests.

>Enshrining "tho shalt never fragment" into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which >regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT >fragmentation.

I'm not suggesting that. If the higher level protocol has definite security checks, or security is not important,
fragmentation is ok. But for DNSSEC neither of these is true.

BTW, I wrongly implied earlier in the thread that the threat was worse if port randomization was not possible.
That's not true, the threat is strong even with port randomization, becaause only the first fragment as the source port
( and DNS ID ). Therefore the only thing protecting the fragment is the 16 bit IP ID field.

In addition, by flooding the victim with fragments, it's probably possible to stop any valid fragment getting through,
so this is a Kaminsky-like attack, the attacker can repeat it as many times as required.

If I'm right, it's currently easy for an attacker to spoof an open cache by sending ANY queries for UK.
The resolver will not normally have any authoritative records, so will send an ANY query to the server,
and the response (which will fragment) can be attacked with success expected after sending ~32K spoof
fragments ( note : these fragments will hang around in re-assembly buffers, so attack is quite efficient ).