Subject: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation

From: Tim Wicinski <[email-masked]>
Date: Tue, 14 Apr 2020 11:47:56 -0400

This starts a Call for Adoption for draft-fujiwara-dnsop-avoid-fragmentation

The draft is available here:
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

We are looking for *explicit* support for adoption.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 28 April 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Bob Harold <[email-masked]>
Date: Tue, 14 Apr 2020 13:10:42 -0400

I support and will review.

-- 
Bob Harold

On Tue, Apr 14, 2020 at 11:48 AM Tim Wicinski <[email-masked]> wrote:

> <https://datatracker..ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Apr 2020 13:32:54 -0400 (EDT)

On Tue, 14 Apr 2020, Tim Wicinski wrote:

> The draft is available here: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
> 

I am in favour of adoption.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to contribute text and review.

What I find missing is some text to explain that this is only a problem
for legacy DNS not using DNSSEC[*] and perhaps even mention that when
resolvers are setting the +DO flag, then fragmentation should still be
avoided, but that this is no longer a security issue.

I think it is important to point out (again) that this issue would have
been a non-issue if people deploy DNSSEC. If we don't keep hammering
that down, people keep being misguided into believing DNSSEC is
optional and a matter of personal taste.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2020 17:44:18 +0000

On Tuesday, 14 April 2020 17:32:54 UTC Paul Wouters wrote:
> > ...

ty!

> optional and a matter of personal taste.

that view, while agreeable, is also very narrow. the draft references three 
sources related to cache poisoning and dnssec:

>    [Fujiwara2018]
>               Fujiwara, K., "Measures against cache poisoning attacks
>               using IP fragmentation in DNS", OARC 30 Workshop , 2019.
>    
>    [Herzberg2013]
>               Herzberg, A. and H. Shulman, "Fragmentation Considered
>               Poisonous", IEEE Conference on Communications and Network
>               Security , 2013.
>    
>    [Hlavacek2013]
>               Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67
>               Meeting , 2013, <https://ripe67.ripe.net/
>               presentations/240-ipfragattack.pdf>.

however, the motivation for this draft is inclusive but not exclusive of those 
sources. see for example:

>    [I-D.ietf-intarea-frag-fragile]
>               Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
>               and F. Gont, "IP Fragmentation Considered Fragile", draft-
>               ietf-intarea-frag-fragile-17 (work in progress), September
>               2019.

and also:

Fragmentation Considered Harmful, Kent, C., Mogul, J., December 1978
https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf

---

what's at issue for fragments and fragmentation is that inter packet gap 
introduced for rate limiting so as to avoid congestion in a UDP-spewing 
service like NFS or DNS, there is no way to avoid microbursts which occur 
below the kernel. thus a steady-state equilibrium maintained with usleep() can 
be fatally upset when fragmentation occurs. this would be true even if PMTUD6 
had actually worked.

we have to never fragment. this draft specifies IP_DONTFRAG and IP6_DONTFRAG 
for that reason. and it's because of that recommendation, it becomes vital 
that we not copy/paste magic numbers like "1232" but rather make a considered 
decision as to what the response size ought to be, assuming that the PMTU is 
either 1500, or something smaller represented by the interface's MTU.

-- 
Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Apr 2020 15:23:01 -0400

Hi Tim, esteemed fellow chairs,

On 14 Apr 2020, at 11:47, Tim Wicinski <[email-masked]> wrote:

> The draft is available here: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/ <https://datatracker..ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/>
> 

I support adoption.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to contribute text, review, etc.

> This call for adoption ends: 28 April 2020

Joe

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 14 Apr 2020 23:43:52 +0400

> Please also indicate if you are willing to contribute text, review, etc.
I support adoption. I'm aware that at least one implementation already
implements this.

Happy to review/contribute text.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 14 Apr 2020 12:51:09 -0700

> by DNSOP, and comments to the list, clearly stating your view.
I support adoption, and am willing to review, contribute text, etc.

Brian

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 15 Apr 2020 03:28:55 +0530

Hi Fujiwara san and Vixie san,

I support adoption.

A quick read through the current revision, and some review notes:

> 1.  Introduction
 
>    As a result, we cannot trust fragmented UDP datagrams, primarily due
>    to the small amount of entropy provided by UDP port numbers and DNS
>    message identifiers, each of which being only 16 bits in size.  By
>    comparison, TCP is considered resistant against IP fragmentation
>    attacks because TCP has a 32-bit sequence number and 32-bit
>    acknowledgement number in each segment.  In TCP, fragmentation should
>    be avoided for performance reasons, whereas for UDP, fragmentation
>    should be avoided for resiliency and authenticity reasons.

Isn't the 16-bit ID field in the IPv4 header the actual reason that we
cannot trust fragmented UDP datagrams? The secondary (following) IPv4
packet fragments don't contain the UDP and DNS headers, so would the UDP
and DNS header field sizes matter?

Isn't TCP resistant because it is performed in a manner that does not
cause IP fragmentation? (e.g., see section 4.1 of
draft-ietf-intarea-frag-fragile-17).

> 3.  Proposal to avoid IP fragmentation in DNS

>    TCP avoids fragmentation using its Maximum Segment Size (MSS)
>    parameter, but each transmitted segment is header-size aware such
>    that the size of the IP and TCP headers is known, as well as the far
>    end's MSS parameter and the interface or path MTU, so that the
>    segment size can be chosen so as to keep the each IP datagram below a
>    target size.  The takes advantage of the elasticity of TCP's
>    packetizing process as to how much queued data will fit into the next
>    segment.  In contrast, DNS has no message size elasticity and lacks
>    insight into IP header and option size, and so must make more
>    conservative estimates about available UDP payload space.

"In contrast, DNS over UDP has no datagram size elasticity ..."

>    The minimum MTU for and for an IPv6 interface is 1280 octets (see
>    Section 5 of [RFC8200]).

s/The minimum MTU for and for an IPv6 interface/The minimum MTU for an IPv6 interface/ ?

> 6.  Request to zone operator and DNS server operator

>    o  Use 'minimal-responses' configuration: Some implementations have
>       'minimal responses' configuration that enables that DNS servers
>       make response packets smaller, mandatory and required data only.

.. and continued in the follow-up text in section 7.2 (DNS packet size):

This text appears to discourage extraneous RRsets in DNS responses. I've
supported this and made implementation changes towards it as they
require more processing per client query.

There were multiple drafts in the last few years proposing myriad ideas
of EDNS0 option and non-option mechanisms to get the server to return
multiple answers and related RRsets within a single response.

Would this draft contradict such drafts, and discourage unnecessary
RRsets in responses (that the server may think may be useful to the
client, but generally is not used)?

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 15 Apr 2020 05:11:46 +0530

>    o  UDP requestors and responders SHOULD send DNS responses with
>       IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
>       either a silent timeout, or a network (ICMP) error, if the path
>       MTU is exceeded.  Upon a timeout, UDP requestors may retry using
>       TCP or UDP, per local policy.

If the IP_DONTFRAG/IP_DF/IP_PMTUDISC_DO option is available and can be
used to set the DF flag on DNS over UDP over IPv4 PDUs, why are any of
the following maximum-size mitigations (the next 3 items after the above
quoted item) necessary?

A large response may be dropped on path, but such conditions are already
expected by resolvers; they make use of the OPT UDP payload size field
to retry to settle on a maximum size that will work with the peer.

It would be helpful to the reader to understand better, if the
requirements of "SHOULD" are annotated with the specific reasons why
that particular item is suggested. The 3 items after the above quoted
item don't specify reasons, and so it's not clear how with DF=1 set,
these items matter.

Off-topic, it appears to me that some of this overlaps with general DNS
over UDP behavior between client server, esp. a resolver vs. upstream. I
am not aware of an RFC/draft that describes in sufficient detail the
tricks (song and dance sequence) that a resolver uses to start
communications with an unknown peer and deal with UDP datagram loss on
path due to a variety of possible factors (loss due to
PMTU/fragmentation+drops, routing, EDNS0 behavior, lack of EDNS support,
etc. some of which was the topic of DNS flag day 2019). A resolver
retries with changes in how it makes its request. IP fragmentation
issues is a subset of this topic of how to communicate with a DNS peer
over UDP. You may want to consider documenting the techniques a client
could use when talking to a peer over UDP.

More generally, a modern day resolver algorithm includes nameserver
selection (SRTT-derived metric, bad peers, transport, etc.), limits on
recursion and indirection, response message processing, etc. These have
security implications and documentation is scant, of low-quality, and
scattered. Documentation for understanding of resolver<->NS
communication behavior is an often-requested item from users.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 15 Apr 2020 06:11:24 +0530

> the following maximum-size mitigations (the next 3 items after the above

Possibly this is client-driven mitigation, right? A client which does
not know if the server will set DF=1 can still avoid fragmentation of
the reply by using a smaller EDNS UDP payload size.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Apr 2020 01:23:14 +0000

first reply:

> the following maximum-size mitigations (the next 3 items after the above

to avoid fragmentation-related loss. all the setting of the DONTFRAG bit does 
is increase the likelihood that fragmentation-related loss will occur and 
cause that loss to occur as close to the responder as possible (thus not 
wasting network capacity on things that won't be delivered) and possibly 
inciting an ICMP that, if sent and if received, will help with manageability.

but while it's important to increase the likelihood of fragmentation-related 
loss and to try to make it happen nearby, it is separately virtuous to avoid 
triggering this loss. the title of the document is "fragmentation avoidance" 
after all. if we intend to avoid fragmentation, we should bet our life on it, 
or at least, bet our response packet's deliverability on it.

> to retry to settle on a maximum size that will work with the peer.

the requestor has no more knowledge of PMTU than the responder does. both 
might be on 9K MTU LANs (ethernet jumbogram) but connected via a whole lot of 
4K MTU WANs (packet on sonet). this document seeks to create the conditions 
under which per-path MTU knowledge can be used, but, without requiring same.

> item don't specify reasons, and so it's not clear how with DF=1 set,

please propose draft text to that effect?

> 
> Off-topic, [...] A resolver
> retries with changes in how it makes its request.

not any more. as you yourself said, the (so-called) DNS-OARC Flag Day of 2019 
removed any duty to retry with changes, and just lets failures be failures.

> IP fragmentation

that's not off-topic. this document is what you're asking for here: set DF, 
pick a defensible response size that takes the offered buffer size as well as 
the local network MTU and any extra knowledge of PMTU into account, and send.

> communication behavior is an often-requested item from users.

on this i agree twice: that it's off topic, and that it's vital information. 
every full resolver has a holddown timer for lame delegations, but only 
because it's a good idea, not because any RFC describes or recommends it.

---

second reply:

> the reply by using a smaller EDNS UDP payload size.

yes, that result could be obtained. but it's not directly intended. rather, 
this document hopes to establish a "reasonableness" threshold on UDP replies, 
and once that threshold becomes the new norm, adaptation such as you describe 
here will be within the realm of experiment. DNS might end up trying a lot of 
different ways to learn what EDNS buffer size will work for any given 
responder. my personal favourite is a binary search among sizes. and since 
modern (IPv6-era) IP stacks allow a host route to be installed to carry the 
path MTU, the PMTU discovered by DNS might then become available to, for 
example, TCP. but all that is stardust at the moment. first we have to nail 
the coffin shut on fragmentation, now that we know PMTUD6 is never coming 
because ICMPv6 was just a thought-experiment that couldn't survive.

-- 
Paul

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 15 Apr 2020 11:18:08 +0200

Moin!

> We are looking for *explicit* support for adoption.
I’m in favour of adaption.

> Please also indicate if you are willing to contribute text, review, 
I am willing to review and maybe contribute text.

So long
-Ralf
——-
Ralf Weber

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 27 Apr 2020 14:06:52 -0400

All

The call for adoption has ended and we've seen consensus to adopt this
draft and for DNSOP to being working on it.

We thank you for this.

tim