Subject: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt

From: [email-masked]
Date: Mon, 27 Jul 2020 19:30:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Fragmentation Avoidance in DNS
        Authors         : Kazunori Fujiwara
                          Paul Vixie
	Filename        : draft-ietf-dnsop-avoid-fragmentation-01.txt
	Pages           : 10
	Date            : 2020-07-27

Abstract:
   EDNS0 enables a DNS server to send large responses using UDP and is
   widely deployed.  Path MTU discovery remains widely undeployed due to
   security issues, and IP fragmentation has exposed weaknesses in
   application protocols.  Currently, DNS is known to be the largest
   user of IP fragmentation.  It is possible to avoid IP fragmentation
   in DNS by limiting response size where possible, and signaling the
   need to upgrade from UDP to TCP transport where necessary.  This
   document proposes to avoid IP fragmentation in DNS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Jul 2020 23:24:18 +0000

please give this a read, especially if you think a dns-oarc flag day related 
to maximum edns payload size is a responsible idea. the draft revision below 
does not include a reference to

https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04

because we weren't aware of it, but the next revision definitely will. our 
thesis is, set the DONTFRAG option on udp sockets on both the initiator and 
the responder, and then follow where that leads.

re:

On Tuesday, 28 July 2020 02:30:29 UTC [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain Name System Operations
> WG of the IETF.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Paul

---

From: Tony Finch <[email-masked]>
Date: Fri, 31 Jul 2020 00:23:27 +0100

I've had a look through and I have a few comments.

Regarding smallest MTUs, I understand from Geoff Huston that it's common
for IPv6 breakage to start at 1281 bytes.

I would find it easier to understand the recommendations if the
requirements for responder and requester were separated. In particular I
don't know how a responder can do MTU discovery (though a simplified
version might be possible).

Here's my understanding of your recommendations:

Requester:

* should have a default EDNS buffer size no more than 1500 bytes (smaller
  than the 4096 that is currently typical, but bigger than the flag day
  recommendation)

* should probe to discover the real MTU per destination, which can be less
  than the default, and use the discovered MTU for the EDNS buffer size in
  queries (resolvers already do this)

* at the moment UDP timeouts don't cause fallback to TCP, but this should
  be added to the list of recovery tactics

* requesters are supposed to guess (how?) the size of response before
  sending a query, so that they can skip UDP and go straight to TCP

* should set the DONTFRAG option, though it's unlikely they are sending
  a query big enough for this to matter. (UPDATE clients need to care,
  though.)

Responder:

* should have a default UDP response size limit of no more than 1500 bytes
  (smaller than the 4096 that is currently typical, but bigger than the
  flag day recommendation)

* should limit response sizes by based on the minimum of the request's
  EDNS buffer size and the server's limit (servers already do this)

* should use minimal responses

* should set the DONTFRAG option on responses

* should listen for ICMP frag needed packets, and react by re-sending the
  response (which is embedded in the ICMP packet) with a TC bit set

Network:

* should send rate-limited ICMP frag needed messages to DNS servers when
  appropriate

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Mull of Kintyre to Ardnamurchan Point: Southeast 4 to 6, occasionally 7 at
first, then veering south 3 to 5 later. Slight or moderate, becoming moderate
or rough near Tiree. Rain at times then fair, then showers later. Moderate or
good.

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 31 Jul 2020 23:35:14 +0200

>   response (which is embedded in the ICMP packet) with a TC bit set

Only part of the response is embedded in the ICMP packet. With some luck, enough of the query is embedded in the ICMP packet (I'm unsure about EDNS). I'm unsure it's even easy for a user space process to get that ICMP packet.

That all said, this sounds like a splendid way to allow 'request spoofing' even if everybody does BCP38 (ingress filtering). The ICMP packet could come from any IP (so no spoofing protection), but the ICMP *payload* which you then treat as believable IP headers is not subject to BCP38 checking, as far as I understand. I know we have a state problem in DNS servers forgetting about a query the moment they responded to it, but I don't think scavenging that query from incoming ICMP packets is the solution.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/