On Fri, Sep 20, 2024 at 7:44 AM, Štěpán Němec <step...@smrk.net> wrote:
> Some minor (editorial) issues I noticed in the current (19) draft: > Thank you very much everyone - this document has been a long time in the making. As mentioned in the document: "This document was originally intended to be a BCP, but due to operating system and socket option limitations, some of the recommendations have not yet gained real-world experience and therefore the document is published as Informational. It is hoped and expected that, as operating systems and implementations evolve, we will gain more experience with the recommendations, and plan to publish an updated document as a Best Current Practice." I'd like to specifically thank the authors (Paul and Fujiwara-san), and Benno, and the implementers for large amounts of constructive discussion, and willingness to compromise to get to this position. I hope that we will soon be able to publish RFCxxxx-bis as a BCP with definitive, tested solutions and advice for fragmentation. I'd like to request that the authors incorporate these last few editorial comments (to make the RFC Editors life easier), and then I will ship it. Much thanks again to everyone, W > 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/ > Actually, I think that the original is better; to me "both" makes the sentence ambiguous (could be read as "UDP port numbers are 16 bit, and DNS message identifiers are 16 bit" or "added together (both) UDP port numbers and DNS message identifiers are 16 bits"). > 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
