Subject: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

From: [email-masked]
Date: Mon, 15 Mar 2021 13:16:04 +0900 (JST)

Dear DNSOP participants,

Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation.

These are my proposal of Section 3.3.  Default Maximum DNS/UDP payload size.

I'm not sure what to do with "MAY, "SHOULD", or "MUST",
so please give us your opinion.

If it is acceptable, I will submit -05.

---------------------------------------------------------------------------
3.3.  Default Maximum DNS/UDP payload size

   Default maximum DNS/UDP payload size depends on the connectivity of
   each node, it cannot be determined unconditinally.  However, there
   are good proposed values.

   Operators MAY select a good number from Table 1.

             +========================+==========+==========+
             |                 Source |     IPv4 | IPv6     |
             +========================+==========+==========+
             |      minimal: RFC 4035 |     1220 | 1220     |
             +------------------------+----------+----------+
             | Software developpers / |     1232 | 1232     |
             | DNSFlagDay2020 propose |          |          |
             +------------------------+----------+----------+
             | This document proposes |     1400 | 1400     |
             +------------------------+----------+----------+
             |  maximum: ethernet MTU |     1472 | 1452     |
             |                   1500 |          |          |
             +------------------------+----------+----------+
             |              calculate | MTU-20-8 | MTU-40-8 |
             +------------------------+----------+----------+

              Table 1: Default maximum DNS/UDP payload size

   However, operators of DNS servers SHOULD measure their path MTU to
   well-known locations on the Internet, such as [a-m].root-servers.net
   or [a-m].gtld-servers.net at setting up the servers.  The smallest
   value of path MTU is the server's path MTU to the Internet.  The
   server's maximum DNS/UDP payload size SHOULD be smaller than or equal
   to the reported path MTU minus IPv4/IPv6 header size (20/40) minus
   UDP header size (8).

   Details of default maximum DNS/UDP payload size is Appendix C.
-----------------------------------------------------------------------------

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Jim Reid <[email-masked]>
Date: Mon, 15 Mar 2021 17:38:40 +0000

> On 15 Mar 2021, at 04:16, [email-masked] wrote:
> 
> Dear DNSOP participants,
> 

Fujiwara-san, “resolvers MAY use PMTU” is probably right. A SHOULD or a MUST seems too strong: for instance when the resolver already has a priori knowledge of the MTU or that’s somehow hard-wired into the link-layer technology end-to-end.

>   or [a-m].gtld-servers.net at setting up the servers.

I think it would be better to replace this with “Operators of DNS servers MAY measure their path MTU.”.

Measuring the MTU to well-known locations on the Internet won’t be appropriate for some use cases. For instance inside private nets that aren’t connected to the Internet or for forwarding-only servers that never query an authoritatve server.

IMO it’s a bad idea to recommend specific servers that could be the target for those PMTU probes. [Suppose those names change one day - unlikely for the above but you never know.] That could become a vector of (D)DoS attacks - probably not on the above name servers themselves but on the access routers in front of them that might well be rate-limiting ICMP packets. This could get nasty with icky CPE firmware: imagine every home router in (say) Comcast’s net doing PMTU to the same root server. Besides, is the PMTU to a root or .com server, going to be the same as that for the example.whatever name servers?

If PMTU is to be used, maybe it needs to be applied to all authoritative name servers a resolver queries? And maybe these will need to be re-probed from time to time, just like how resolving servers continually monitor RTTs to authoritative servers. PMTUs might well change when the links and routes change.

I think it would also be helpful to discuss some of the trade-offs of using PMTU for DNS resolution. Some of these are mentioned in RFC8899. I’m sure PMTU will unquestionably be the right thing to do in some settings. But in others, it could cause more operational trouble than fragmented DNS packets: increased latency for example. It would be great if the ID helped developers and operators to make informed choices on when to use or not use PMTU.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 18 Mar 2021 22:42:51 -0400

> servers MAY measure their path MTU.”.

Sadly, we don't have a keyword that's midway between MAY and SHOULD, I
used to think that RECOMMENDED was it, but I was disabused of that
mistake some time back.  I think that the suggestion to measure the
path MTU is good advice.

The key thing to note is that in the resolver case this is only
applicable to full-service resolvers that directly query public
authoritative servers, and in the authoritative server case this
applies to servers serving public-Internet facing zones.

> Measuring the MTU to well-known locations on the Internet won’t be
> appropriate for some use cases. For instance inside private nets that
> aren’t connected to the Internet or for forwarding-only servers that
> never query an authoritatve server.

Right, the forwarding-mostly (or only) servers should just measure the
PMTU to the relevant upstream(s).

> IMO it’s a bad idea to recommend specific servers that could be the
> target for those PMTU probes. [Suppose those names change one day -
> unlikely for the above but you never know.] That could become a vector
> of (D)DoS attacks - probably not on the above name servers themselves
> but on the access routers in front of them that might well be
> rate-limiting ICMP packets.

I don't see the DDoS, such measurements should be rather infrequent, in
particular, I don't see why these would be much more frequent than root
zone priming queries, which full service resolvers do routinely at
startup.

> This could get nasty with icky CPE
> firmware: imagine every home router in (say) Comcast’s net doing PMTU
> to the same root server.

These would generally not all boot up at the same time, and would be
expected to be configured in forward-only mode to the relevant Comcast
iterators.

> Besides, is the PMTU to a root or .com server, going to be the same as
> that for the example.whatever name servers?

But the proposal remains sound, because that server also measures its
PMTU to the root, and assuming PMTU reduction happens mostly at the
respective edges of the network, and not in the core, the lower of
the two PMTUs to some suitable core nodes would typically also be
the PMTU end-to-end between them.

Thus if a full-service iterator bases its EDNS UDP size on its PMTU
to the core, and the authoritative server replies with a size that
is at most its respective PMTU, you'll most often end up with a
workable lower-bound.

> If PMTU is to be used, maybe it needs to be applied to all
> authoritative name servers a resolver queries?

Not needed, on the assumption that the path from each to the
core is as "wide" as the path from either a common core node.

-- 
    Viktor.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 19 Mar 2021 10:04:28 -0400

Hi,

On Thu, Mar 18, 2021 at 10:43 PM Viktor Dukhovni <[email-masked]> wrote:
> > ...
> ...
> These would generally not all boot up at the same time, ...

When power is restored after a widespread power outage, vast numbers
of CPEs can boot up at more or less the same time.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Fri, 19 Mar 2021 14:22:52 +0000

> PMTU to the relevant upstream(s).

The current draft says nothing about this. I’m suggesting it should.

> zone priming queries, which full service resolvers do routinely at

The PMTU probing rate could well end up being broadly similar to the rate of priming queries to the root. However those priming queries are almost certainly not going to result in ICMP responses. Which usually take a different code path through routers and get rate-limited. Which means PMTU probing could be a vector for (D)DoS attacks: not on the well-known authoriatative name servers but the access routers and firewalls in front of them.

> expected to be configured in forward-only mode to the relevant Comcast

It’s unwise to make these assumptions. Besides, Comcast’s net and CPE configuration isn’t the only game in town.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Mar 2021 21:22:44 -0700

> If it is acceptable, I will submit -05.
Fujiwara-san, please consider the following addition at this place in the
proposed text:

The default maximum DNS/UDP payload size MUST NOT exceed the calculated
value
based on the outgoing interface MTU. It MAY be configured lower than this
value, based

on knowledge of the operator's network vicinity and minimum link MTU of
that vicinity,

or operator preference using the table below.

>    Operators MAY select a good number from Table 1.
Similarly, I have a suggestion for replacement text for the next sentence:

However, operators of DNS servers SHOULD adjust the maximum DNS/UDP

payload size at installation/configuration time, or at start-up time,
accordingly.

Clients SHOULD perform MTU validation* (rather than discovery per se)
towards

configured resolvers at start-up. Authority servers' operators SHOULD
monitor
for PTB messages, and passively collect TCP MTU values, and adjust
accordingly.

(* I have a separate suggestion for a mechanism for validating MTU, which I
will send

to the list separate from this.)

>    or [a-m].gtld-servers.net at setting up the servers. The smallest

   value of path MTU is the server's path MTU to the Internet.

Then, in this section, substitute "configured or adjusted" for "reported".

The
>    to the reported path MTU minus IPv4/IPv6 header size (20/40) minus
Sincerely,
Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Mar 2021 21:39:12 -0700

Fujiwara-san,

I have a suggestion on tweaking the wording of Section 1, Introduction.
The intent is to simplify it a bit. Feel free to ignore this if it doesn't
work,
or use whatever parts of it you feel are useful.

DNS has EDNS0 [RFC6891] mechanism.  It enables a DNS server to send
   large responses using UDP.  EDNS0 is now widely deployed, and DNS
   (over UDP) is said to be the biggest source of IP fragments.

Fragmented DNS UDP responses have systemic weaknesses, which expose
the requestor to DNS cache poisoning from off-path attackers. (See appendix
for references and details.) The primary weakness is the UDP checksum
itself,
and the fact that the UDP header and DNS header will be in the first
fragment only.
In addition, the IPv4 fragmentation and reassembly relies solely on the
IPv4 ID,
a 16-bit value which is weak enough to permit feasible brute force attacks.

UDP has no inherent ability to react to ICMP messages that would otherwise
alert
the sender to dropped packets with DF=1, due to MTU being exceeded.
Additionally, fragmentation can adversely affect TCP performance, thus the
same logic
is applicable to both UDP and TCP. Fragmentation SHOULD be avoided.

This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP
   messages in order to avoid IP fragmentation, and describes how to
   avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG.

(Place the rest of the original introduction text and references into an
Appendix.)

Feedback concerning this suggestion is welcome.

Sincerely,
Brian Dickson

---

From: [email-masked]
Date: Tue, 30 Mar 2021 16:53:16 +0900 (JST)

Thanks very much.

I will refer to your suggestions and try to shorten the introduction
section.

> From: Brian Dickson <[email-masked]>
> Fujiwara-san,
> 
> The intent is to simplify it a bit. Feel free to ignore this if it doesn't work,
> for references and details.) The primary weakness is the UDP checksum itself,
> and the fact that the UDP header and DNS header will be in the first fragment only.
> In addition, the IPv4 fragmentation and reassembly relies solely on the IPv4 ID,
> UDP has no inherent ability to react to ICMP messages that would otherwise alert
> Additionally, fragmentation can adversely affect TCP performance, thus the same logic
> (Place the rest of the original introduction text and references into an Appendix.)
>