Skip to main content

Last Call Review of draft-ietf-dnsop-avoid-fragmentation-15
review-ietf-dnsop-avoid-fragmentation-15-artart-lc-leiba-2023-10-23-00

Request Review of draft-ietf-dnsop-avoid-fragmentation
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-10-27
Requested 2023-10-13
Authors Kazunori Fujiwara , Paul A. Vixie
I-D last updated 2023-10-23
Completed reviews Dnsdir Telechat review of -16 by Vladimír Čunát (diff)
Artart Telechat review of -16 by Barry Leiba (diff)
Secdir Telechat review of -16 by Donald E. Eastlake 3rd (diff)
Dnsdir Last Call review of -15 by Vladimír Čunát (diff)
Artart Last Call review of -15 by Barry Leiba (diff)
Tsvart Last Call review of -15 by Mirja Kühlewind (diff)
Dnsdir Last Call review of -13 by Vladimír Čunát (diff)
Secdir Last Call review of -15 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -15 by Christer Holmberg (diff)
Assignment Reviewer Barry Leiba
State Completed
Request Last Call review on draft-ietf-dnsop-avoid-fragmentation by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/Bgw7Ow7b3atOZJYNX7h4zi33VYc
Reviewed revision 15 (document currently at 17)
Result Ready w/issues
Completed 2023-10-23
review-ietf-dnsop-avoid-fragmentation-15-artart-lc-leiba-2023-10-23-00
Thanks for an easy-to-read and useful document.  I have just a few minor issues
to raise here:

— Section 1 —

   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.

This sentence seems too long and somewhat convoluted.  Perhaps split it into
two sentences to make it easier on the reader?

— Section 3.1 —

   R2.  UDP responders MAY set IP "Don't Fragment flag (DF) bit"
   [RFC0791] on IPv4.

But Section 1 says, “This document proposes that implementations set the ‘Don't
Fragment (DF) bit’ on IPv4 and not use the ‘Fragment header’ on IPv6….”  That
(“proposes”) seems like it should be stronger than “MAY”, no?

Section 7.1 touches on this, but maybe either R2 or Section 7.1 should explain
why it’s “MAY” (which arguably is saying nothing at all, because,well, of
course they may), and what needs to happen before it becomes SHOULD.

— Section 4 —

   Large DNS responses are the result of zone configuration.

I understand what you’re saying here (you’re referring to retrieving A/AAAA
records), but in many cases large responses come from retrieving TXT records,
and this sort of thing could get worse as key lengths, signatures, and the like
get larger (you hint at this last bit in R12).  Maybe “Large DNS responses are
often the result…,” or otherwise clarify that you’re talking about queries for
IP addresses in particular.

— Section 7.2 —

   If a UDP response packet is dropped (for any reason), it increases
   the attack window for poisoning the requestor's cache.

But Section 3.2 says this:

   R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
   reassembly to avoid cache poisoning attacks.

…which seems to be contradictory.  Can you clarify this apparent contradiction
in one place or both?