Telechat Review of draft-ietf-dnsop-avoid-fragmentation-16
review-ietf-dnsop-avoid-fragmentation-16-secdir-telechat-eastlake-2023-12-27-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Ready with Issues.

Security
--------

In Section 7.3, the second paragraph on DNSSEC does not seem to belong in a
section on "Weaknesses of IP fragmentation". I suggest moving it to a new
Section 7.4 entitled "DNS Security Protections" or the like.

Not only should the existing DNSSEC material be moved there but there
should be some mention of transaction authentication. The existing document
completely ignores RFC 8945 and RFC 2931 transaction authentication which,
it seems to me, when used, overcome the security infirmities of fragmented
UDP. Furthermore, transaction security protects delegation responses.
Perhaps adding something like "DNS transaction security [RFC8945] [RFC2931]
does protect against the security risks of fragmentation including
protecting delegation responses. But [RFC8945] has limited applicability
due to key distribution requirements and there is little if any deployment
of [RFC2931]."

There seem to be inconsistent implementation requirements for
recommendation R7. R7 itself says "MAY" but Section 7.1 says "should" in
such a way that I think it should be capitalized "SHOULD". Also, I think
the last sentence of 7.1 should be deleted and recommendation R2 made a
"SHOULD".

Minor
-----

This draft has scattered statements in it that seem in need of
qualification or rewording to be correct.

Abstract: "Large DNS/UDP responses are fragmented" -> "Larger DNS/UDP
messages are more likely to be fragmented" Couldn't a request have lots of
Additional Information RRs and be large?

Section 1. Introduction:, last sentence of first paragraph: It isn't the
DNS buffer size that causes fragmentation, it's caused by big packets.
There may be applications where all the packets are not that large. There
are lots of ways to fix this sentence, of which perhaps the simplest would
be to add "In the general case" to the beginning of the sentence. Other
possibilities are things like "DNS over UDP relies on IP fragmentation when
a packet is larger than the path MTU, which is invited by an EDNS buffer
size larger than the path MTU."

Section 1. Introduction, first sentence of 3rd paragraph top of page 3:
summarized -> states

Section 1. Introduction, last paragraph, page 3: First sentence is fine. I
don't understand just what the rest of the paragraph is saying or why it is
useful. A "path MTU" can be "obtained" (not set?) through "static
configuration, server routing hints, ..."? Is this configuration/hint
affecting transit devices so as to limit/expand the path MTU? What's going
on here?

Section 3., first paragraph: So, down here we learn that private/local
networks are out of scope. This limitation should be earlier, like in the
Abstract and Introduction. I also suggest considering flipping it around
and saying "This document is primarily applicable to DNS use on the global
Internet."

R2: While a BCP certainly shouldn't say "MUST" for something that is
"currently impossible", I don't see why it can't say "SHOULD" to push
things in the right direction. "MAY" is pretty wimpy.

R5 seems redundant with part of R3.

The last sentence in Section 3.1, which is after R5, seems more applicable
to R4 and should probably be moved up to between R4 and R5. Also, that
sentence uses RFC 6891 as the reference for "the TC bit". But the TC bit
has only one minor occurrence in RFC 6891. I believe RFC 1035 is the
appropriate reference.

Section 7.2 says "... fragmentation, which is universally considered to be
harmful ..." I don't like "universally" as it might overpower the scope
limitation to exclude private/local networks in some readers' minds and it
is my understanding that within an over provisioned local network,
fragmentation can be quite reliable and improve performance. How about "...
fragmentation, which is considered harmful on the global Internet"?

Appendix C: I think you should make up your mind and either tell the RFC
Editor to remove this before publication or to retain it. I would
definitely lean towards removal.

Nits
----

R1: 'without "Fragment' -> 'without a "Fragment'

R2: "OS" is used only once here in the explanation after the
recommendation. Just spell it out.

R4: "in path MTU size" -> "in the path MTU size"

Section 4: The first two recommendations do not end with a period although
all other recommendations do end with a period.

Section 5: I would add something right after the Section 5 header like
"Some authoritative servers deviate from the DNS standard as follows:" and
then make the current first two sentences in Section 5 indented and/or
numbered or otherwise clearly a list.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com