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

From: [email-masked]
Date: Mon, 05 Nov 2018 01:36:07 +0900 (JST)

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 <[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Nov 2018 08:52:42 +1100

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, [email-masked] wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Nov 2018 18:53:00 +0000

[email-masked] <[email-masked]> wrote:

> DNS with TCP transport is enough, I think.

Yes, and I think there's a slightly deeper argument here. The DNS is
suffering from relatively poor transport protocol engineering.
Fragmentation and pMTUd woes are one aspect of it; bad tuning of timeouts
is another; and security, and privacy, etc.

Rather than wedging transport features into the DNS, a better strategy is
to use off-the-shelf transport layers, which have much greater investment
in expertise and engineering.

I'm looking forward to QUIC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Cyclonic becoming southwesterly, 6 to gale 8, occasionally severe gale
9 at first in south. Rough or very rough, occasionally moderate. Rain or
thundery showers. Good, occasionally poor.

---

From: [email-masked]
Date: Wed, 21 Nov 2018 18:57:18 +0900 (JST)

Sorry, too late response. I could not understand second paragraph about TSIG.

> From: Mark Andrews <[email-masked]>

Thanks. I agree. 

I mainly concerned on IPv4. Dropping IPv4 ICMP "fragmentation needed
and DF set" and IPv6 PTB may cause TCP problem.

Then my proposal changed as follows:

  Authoritative servers should set static EDNS buffsize 1220.
  (and set DF bit in responses on IPv4).

  Full-service resolvers should set static EDNS buffsize 1220
  and should drop fragmented DNS response packets by packet filters.

    IPv4: drop UDP and source port 53, More fragment bit = 1
    IPv6: drop packets that have NextHeader = Fragment,
    	  fragment offset=0, more fragment = 1, hext header=UDP
	  UDP, source port 53

  TCP will work if the end node is under ICMP PTB/need fragment attack
    and path MTU becomes under 300.

> the well known key.  This is easy to test with tools like dig.

Do you mean TSIG protects from second fragmentation attacks ?

Regards,