On 26. 07. 22 23:13, Suzanne Woolf wrote:
Dear colleagues,
This message starts the Working Group Last Call for
draft-ietf-dnsop-avoid-fragmentation
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The
requested status is BCP.
Since we're starting the Last Call during the IETF week, and many folks are on
holidays in the next few weeks, the WGLC will end in three weeks (instead of
the usual two), on August 16.
Substantive comments to the list, please. It’s fine for minor edits to go
direct to the authors. We need to hear positive support to advance it, or your
comments on what still needs to be done.
Given the fact that most open-source implementations already avoid
fragmentation in one way or another, there is no harm in publishing
"don't fragment" as a RFC, but there is also only limited benefit.
Attacks and problems were years ahead and implementers had to patch
software years ago.
After a quick re-read I agree with the idea but there are implementation
details which are not as simple as laid out in the current text.
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.
IP_DONTFRAG and its interaction with networking stack and socket
interface is complex and possibly OS-dependent.
I don't remember all the gory details but BIND went through several
iterations of this and currently we use:
- IP_DONTFRAG - socket option disabled (i.e. fragmentation allowed)
- IP_MTU_DISCOVER = IP_PMTUDISC_OMIT (which is woefully undocumented in
man pages, see https://lists.openwall.net/netdev/2014/02/26/4)
State in other resolvers is somewhat summarized here:
- https://github.com/PowerDNS/pdns/pull/7410/files#r250252209
- https://www.yadifa.eu/archives/yadifa-users/2019-March/000133.html
(From a quick glance it seems we all do the same, or at least try.)
IIRC this was needed to protect from attacks using spoofed Path MTU.
This risk really should be mentioned in the document and discussed. RFC
8201 section 6 is not theoretical, we have seen weird things happen in
real networks. CVE-2021-25218 is my witness :-)
Maybe the currently empty section 8. Security Considerations needs to
copy RFC 8201 section 6 and then conclude that it is insecure anyway, so
don't do it?
I'm not sure how to proceed. On one hand IP_DONTFRAG sounds like a good
idea. On the other hard it does weird things when combined with
IP_MTU_DISCOVER IP_PMTUDISC_OMIT/_DONT. Maybe DNS is even the right
place to start and we should be poking OS people to fix/improve it? I
don't know.
Except for the fundamental problem mentioned above I have just smaller
things:
3.2. Recommendations for UDP requestors > * DNS responses may be dropped
by IP fragmentation. Upon a timeout,
UDP requestors may retry using TCP or UDP, per local policy.
To avoid name resolution fails, UDP requestors need to retry using
TCP, or UDP with smaller maximum DNS/UDP payload size.
The last sentence does not have a normative language and which is IMHO
good, but it slightly errs on side of working around brokenness. ("need
to retry ...")
I think the document should not have the last sentence at all and leave
it with up to implementations to do handle timeouts as they like it.
4. Incremental deployment
I'm not sure if it belongs here to a new "Implementation Status"
section, but I think it's worth mentioning that this document is almost
no-op after https://dnsflagday.net/2020/ .
The default EDNS buffer size have been changed to, sometimes, even lower
values so the fragmentation should not happen anymore.
6.1. Protocol compliance
+1 (or all votes I can possibly hands on!)
--
Petr Špaček
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
