Thanks very much for your review. I submitted -20 now.
Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Štěpán Němec <step...@smrk.net> > Some minor (editorial) issues I noticed in the current (19) draft: > > 3.1 > > R4. If the UDP responder detects an immediate error indicating that > the UDP packet cannot be sent beyond the path MTU size, the UDP > responder may recreate response packets fit in the path MTU size, or > with the TC bit set. > > s/packets fit/packets that fit/ ? Or perhaps "to fit"? > > I also find "the UDP packet cannot be sent beyond the path > MTU size" hard to interpret (specifically the "sending > beyond the path MTU size" part), do you mean "packet exceeds > the path MTU size"? > > 3.2. Proposed Recommendations for UDP requestors > > R5. UDP requestors should limit the requestor's maximum UDP payload > size that fit in the minimum of the interface MTU, the network MTU > value configured by the knowledge of the network operators, and the > RECOMMENDED maximum DNS/UDP payload size 1400. A smaller limit may > be allowed. (See Appendix A for more information.) > > s/that fit/to fit/ ? > s/by the knowledge of the network operators/by the network operators/ ? > Or perhaps "according to the knowledge of the network" (not operators)? > > 4. Proposed Recommendations for DNS operators > > Large DNS responses are typically the result of zone configuration. > People who publish information in the DNS should seek configurations, > resulting in small responses. > > The comma makes no sense here (should be dropped). > > 7.1. On-path fragmentation on IPv4 > > If the Don't Fragment (DF) bit is not set, on-path fragmentation may > happen on IPv4, and be vulnerable, as shown in Section 7.3. To avoid > this, recommendation R6 need to be used to discard the fragmented > responses and retry by TCP. > > s/be vulnerable/lead to vulnerabilities/ ? > s/R6 need/R6 needs/ (or "should") > > 7.3. Weaknesses of IP fragmentation > > [...] > "Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed > that off-path attackers can intervene in the path MTU discovery > [RFC1191] to perform intentionally fragmented responses from > authoritative servers. > > I didn't manage to obtain free access to the paper in the > limited time I was willing to spend on the matter, but the > way such papers are usually written is they describe attacks > and propose solutions, not the other way round (and the > abstract[1] seems to confirm that prejudice), so: > > s/proposed/noted/ ? > > And perhaps also rather "cause authoritative servers to > return/produce fragmented responses"? > > [...] > 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, and both likely being in the first fragment of a packet if > fragmentation occurs. > > s/each of which/both/ > > 7.5. Possible actions for resolver operators > [...] > Specifically, config the firewall functions before the full-service > resolver to discard incoming DNS response packets > > s/config/configure/ > s/before/in front of/ ? Or "protecting", to avoid any > spacial vs. temporal ambiguity? > > Appendinx A. > [...] > in the interior of the > Internet between recursive resolvers and authoritative servers the > prevailing MTU is at 1,500 > > I realize this comes verbatim from the report text[2], but > for consistency/PoLA I suggest s/is at 1,500/is 1500/ (with > all the numbers and plus/minus/maximum/at least flying > around in the document I was at first wondering if "least" > might be missing after "at", and the comma is distracting at > best). Failing that, add quotation marks so that it is > clear that this is a quote from another document (following > different style). > > Thank you, > > Štěpán > > [1] https://dl.acm.org/doi/10.1145/3243734.3243790#abstract > > [2] > https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf > p. 27: > "Our measurements suggest that in the “interior” of the Internet between > recursive > resolvers and authoritative servers the prevailing MTU is at 1,500." > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
