Re: [DNSOP] DNS without Fragmentation (UDP and DF bit set)

Mark Andrews <marka@isc.org> Sun, 04 November 2018 21:52 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40AA12872C for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 13:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZoNyAa2AGAWt for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 13:52:47 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF52128CE4 for <dnsop@ietf.org>; Sun, 4 Nov 2018 13:52:46 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 483443AB2A6; Sun, 4 Nov 2018 21:52:46 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 36AF4160077; Sun, 4 Nov 2018 21:52:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 27F63160076; Sun, 4 Nov 2018 21:52:46 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E93_9OO8-kf7; Sun, 4 Nov 2018 21:52:46 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3C08C160036; Sun, 4 Nov 2018 21:52:45 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20181105.013607.854519297338098286.fujiwara@jprs.co.jp>
Date: Mon, 05 Nov 2018 08:52:42 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEE1DC56-A2FA-46BA-8824-396E62EF1985@isc.org>
References: <20181105.013607.854519297338098286.fujiwara@jprs.co.jp>
To: fujiwara@jprs.co.jp
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bDfq98nSvGy6e_zw8emBNoF4bIk>
Subject: Re: [DNSOP] DNS without Fragmentation (UDP and DF bit set)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 04 Nov 2018 21:52:51 -0000

Firstly you are insane to recommend dropping PTB’s.  That will break lots of things
including TCP.

Secondly we could just use a well known TSIG key and have the authoritative servers add
it to their configuration today, especially the root and TLDs servers.  The recursive
servers could also add the key for root and TLD servers they know have installed the
the well known key.  This is easy to test with tools like dig.

e.g.

key "." {
        algorithm hmac-sha256;
        secret "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};

server <address> { key “.”; };

Auto configuring the key can come in the next revision of the software and would handle
FORMERR/NOTIMP (STD-13 errors) and NOTAUTH/BADKEY (expected error from TSIG implementations)
by falling back to non-TSIG queries when talking to a server using the well known key without
it being explicitly configured.  If using the well known key with a server is explicitly
configured fallback to non-TSIG messages would not occur.

Yes, some implementations may need to add TSIG support.  The majority already support
TSIG, it is just a matter of configuring the key.

https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt

Below are typical error responses as well as a one from a server with the key configured.

% dig soa . @b.root-servers.net -y hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; Couldn't verify signature: tsig indicates error

; <<>> DiG 9.13.1 <<>> soa . @b.root-servers.net -y hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTAUTH, id: 42384
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: af1f5afe5008ef28ac57d36f5bdf617e3364284dfc68df28 (good)
;; QUESTION SECTION:
;.				IN	SOA

;; TSIG PSEUDOSECTION:
.			0	ANY	TSIG	hmac-sha256. 1541366142 300 0  42384 BADKEY 0 

;; Query time: 178 msec
;; SERVER: 199.9.14.201#53(199.9.14.201)
;; WHEN: Mon Nov 05 08:15:42 AEDT 2018
;; MSG SIZE  rcvd: 96
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @a.root-servers.net -y hmac-sha256:.: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; Couldn't verify signature: expected a TSIG or SIG(0)

; <<>> DiG 9.13.1 <<>> soa . @a.root-servers.net -y hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 38857
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; Query time: 279 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Nov 05 08:14:45 AEDT 2018
;; MSG SIZE  rcvd: 12
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @127.0.0.1 -y hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= 
;; BADCOOKIE, retrying.

; <<>> DiG 9.13.1 <<>> soa . @127.0.0.1 -y hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63699
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a2986dd7ec4014f14a25b1d85bdf6805e53cda0537bd7b68 (good)
;; QUESTION SECTION:
;.				IN	SOA

;; ANSWER SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018110401 1800 900 604800 86400

;; TSIG PSEUDOSECTION:
.			0	ANY	TSIG	hmac-sha256. 1541367813 300 32 NJNkcTXIjQ4PWVc6o9RNqXIzjofXDMpTlrXCEKJ1EQ4= 63699 NOERROR 0 

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 05 08:43:33 AEDT 2018
;; MSG SIZE  rcvd: 203

% 

Mark

> On 5 Nov 2018, at 3:36 am, fujiwara@jprs.co.jp wrote:
> 
> It is time to drop fragmentation (and pMTU discovery) in DNS.
> 
> A research paper showed that there are many authoritative servers that
> accept any ICMP destination unreachable / fragmentation needed and DF
> set (pMTU response packets) and reduce packet size up to 296 bytes.
> Path MTU discovery is controlled by any attacker.  Then the authors
> sent trigger queries and did second fragmentation attack to CA's
> resolvers.
> 
>  https://dl.acm.org/citation.cfm?id=3243790
>  Domain Validation++ For MitM-Resilient PKI
>  Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner
>  Fraunhofer SIT, TU Darmstadt
> 
> Proposed solution is not good. DNS with TCP transport is enough, I think.
> 
> I would like to propose to drop fragmentation and pMTU discovery in DNS.
> 
> Authoritative servers should drop ICMP fragmentation needed,
> set static EDNS buffsize 1220, and set DF bit in responses.
> 
> On resolver machines, I would like to drop fragmented response packets.
> We can write IP filter that drop fragmented packet to resolvers,
> but it is not beautiful.
> 
> --
> Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org