Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!--[rfced] We have updated the short title that spans the header of the PDF file from "avoid-fragmentation" to "Avoid IP Fragmentation". Please review and let us know if any further changes are desired. Original: avoid-fragmentation Current: Avoid IP Fragmentation --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!--[rfced] How may we make these sentences clearer? Specifically, what does "other end" refer to in "keep it within the other end's MSS" - is it the other end of the segment? Also, does "as to how much queued data will fit" mean "depending on how much queued data will fit"? Please advise. Original: For each transmitted segment, the size of the IP and TCP headers is known, and the IP packet size can be chosen to keep it within the estimated MTU and the other end's MSS. This takes advantage of the elasticity of TCP's packetizing process as to how much queued data will fit into the next segment. Perhaps: For each transmitted segment, the size of the IP and TCP headers is known, and the IP packet size can be chosen to keep it within the estimated MTU and the MSS of the other end of the segment. This takes advantage of the elasticity of the TCP's packetizing process, depending on how much queued data will fit into the next segment. --> 4) <!-- [rfced] FYI: In Section 2, we placed the definitions that are direct quotes within the <blockquote> element, and we updated the text slightly to exactly match the quoted text in RFCs 6891 and 8201. Please review and let us know of any concerns. Original: "Requestor" refers to the side that sends a request. "Responder" refers to an authoritative server, recursive resolver or other DNS component that responds to questions. (Quoted from EDNS0 [RFC6891]) "Path MTU" is the minimum link MTU of all the links in a path between a source node and a destination node. (Quoted from [RFC8201]) Current: The definitions of "requestor" and "responder" are per [RFC6891]: "Requestor" refers to the side that sends a request. "Responder" refers to an authoritative, recursive resolver or other DNS component that responds to questions. The definition of "path MTU" is per [RFC8201]: path MTU [is] the minimum link MTU of all the links in a path between a source node and a destination node. --> 5) <!--[rfced] Section 3.2. We find the use of "should/may" confusing. Is using only "should" or "may" acceptable? Please advise. Original: R6. UDP requestors should/may drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks (at firewall function). Perhaps: R6. UDP requestors may drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks (at the firewall function). --> 6) <!-- [rfced] For clarity, may we update the following sentence as shown below since some of the text is a direct quote from RFC 8085? Current: In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines [RFC8085] we are told that an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Perhaps: Section 3.2 of [RFC8085] states that "an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination". --> 7) <!-- [rfced] Informative Reference URLs a) We found the following URL for [Brandt2018]: https://dl.acm.org/doi/10.1145/3243734.3243790. May we update this reference to use this URL? Original: [Brandt2018] Brandt, M., Dai, T., Klein, A., Shulman, H., and M. Waidner, "Domain Validation++ For MitM-Resilient PKI", Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security , 2018. Perhaps: [Brandt2018] Brandt, M., Dai, T., Klein, A., Shulman, H., and M. Waidner, "Domain Validation++ For MitM-Resilient PKI", Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 2060-2076, DOI 10.1145/3243734.3243790, October 2018, <https://dl.acm.org/doi/10.1145/3243734.3243790>. b) We found the following URL for [Herzberg2013]: https://ieeexplore.ieee.org/document/6682711. May we update this reference to use this URL? Original: [Herzberg2013] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", IEEE Conference on Communications and Network Security , 2013. Perhaps: [Herzberg2013] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous, or: One-domain-to-rule-them-all.org", IEEE Conference on Communications and Network Security (CNS), DOI 10.1109/CNS.2013.6682711, 2013, <https://ieeexplore.ieee.org/document/6682711>. c) We found the following URL for [Fujiwara2018]: https://indico.dns-oarc.net/event/31/contributions/692/ attachments/660/1115/fujiwara-5.pdf. May we update this reference to use this URL? Original: [Fujiwara2018] Fujiwara, K., "Measures against cache poisoning attacks using IP fragmentation in DNS", OARC 30 Workshop , 2019. Perhaps: [Fujiwara2018] Fujiwara, K., "Measures against DNS cache poisoning attacks using IP fragmentation", OARC 30 Workshop, 2019, <https://indico.dns-oarc.net/event/31/contributions/692/ attachments/660/1115/fujiwara-5.pdf>. d) We found the following URL for [Huston2021]: https://indico.dns-oarc.net/event/37/contributions/806/ attachments/782/1366/2021-02-04-dns-flag.pdf. May we add this URL to the reference? Original: [Huston2021] Huston, G. and J. Damas, "Measuring DNS Flag Day 2020", OARC 34 Workshop , February 2021. Perhaps: [Huston2021] Huston, G. and J. Damas, "Measuring DNS Flag Day 2020", OARC 34 Workshop, February 2021, <https://indico.dns-oarc.net/ event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf> --> 8) <!--[rfced] FYI: To match the quoted text in Section 3 of RFC 4035, we updated the text below to include a reference to RFC 2671, and we listed RFC 2671 as an informative reference. Original: [RFC4035] defines that "A security-aware name server MUST support the EDNS0 message size extension, MUST support a message size of at least 1220 octets". Current: [RFC4035] states that "A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, [and it] MUST support a message size of at least 1220 octets". --> 9) <!--[rfced] Regarding Appendix C ("Known Implementations"), is it your intention that this section remain in the RFC? The reason we ask is because RFC 7942 recommends removing it but also states that it is not mandatory to remove it. --> 10) <!--[rfced] Since this document is "Informational", is it correct to state that this specification defines "best practices", or does this text need an update to avoid any confusion? Original: This section records the status of known implementations of these best practices defined by this specification at the time of publication, and any deviation from the specification. --> 11) <!-- [rfced] Appendix C.1 a) We notice inconsistencies with the recommendation numbers, for example, "recommendation R6", "recommendation 2", and "R5". May we use "R#" for consistency below and throughout the document? Please let us know your preference. b) We find "the first recommendation of Section 3.2" and "recommendation 2 of Section 3.2" (which should be "R6") confusing. For clarity, may we add section numbers for the recommendation numbers that do not have them and update the text as shown below? c) Please confirm if "recommendation 3" in the last entry is referring to R7 of Section 3.2. Original: BIND 9 does not implement the recommendations 1 and 2 in Section 3.1 For recommendation 3, BIND 9 will honor the requestor's size up to the configured limit (max-udp-size)... In the case of recommendation 4, and the send fails with EMSGSIZE, BIND 9 set the TC bit and try to send a minimal answer again. In the first recommendation of Section 3.2, BIND 9 uses the edns-buf-size option, with the default of 1232. BIND 9 does implement recommendation 2 of Section 3.2. For recommendation 3, after two UDP timeouts, BIND 9 will fall back to TCP. Perhaps: BIND 9 does not implement R1 and R2 in Section 3.1. For R3 (Section 3.1), BIND 9 will honor the requestor's size up to the configured limit (max-udp-size)... In the case of R4 (Section 3.1) and the send fails with EMSGSIZE, BIND 9 sets the TC bit and tries to send a minimal answer again. For R5 (Section 3.2), BIND 9 uses the edns-buf-size option, with the default of 1232. BIND 9 does implement R6 (Section 3.2). For R7 (Section 3.2), after two UDP timeouts, BIND 9 will fall back to TCP. c) How may we update this sentence for clarity? Does BIND 9 cause IP_DONTFRAG to be disabled? If so, may we add "When" as shown below? Original: BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is disabled. Perhaps: When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is disabled. --> 12) <!--[rfced] May we make the first three bulleted items into complete sentences for clarity? Also, is "Spoofing nearmisses" a specific term, or may we add a space to "nearmisses" per its dictionary spelling? And does this quoted term need a reference for background, or will readers be familiar with it? Original: * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT * default EDNS buffer size of 1232, no probing for smaller sizes * no handling of EMSGSIZE * Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing nearmisses" do. Perhaps: * Use IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT * The default EDNS buffer size is 1232; no probing for smaller sizes. * There is no handling of EMSGSIZE. * Recursor: UDP timeouts do not cause a switch to TCP; "Spoofing near misses" do. --> 13) <!--[rfced] Please clarify what "if that is smaller" means as the text states that Unbound requests size 1232 and then it retries with a smaller size of 1232 for IPv6, which is confusing. Is the intended meaning perhaps that Unbound retries with a smaller size "if applicable"? Also, please clarify the intended meaning of "anything" in "This does not do anything". Additionally, should a citation be included for "flag day", either [DNSFlagDay2020] or [Huston2021], for easy reference? Note that the preceding sentence is included for context. Original: Unbound requests UDP size 1232 from peers, by default. The requestors size is limited to a max of 1232. After some timeouts, Unbound retries with a smaller size, if that is smaller, at size 1232 for IPv6 and 1472 for IPv4. This does not do anything since the flag day change to 1232. Perhaps: Unbound requests a UDP size of 1232 from peers, by default. The requestor's size is limited to a max of 1232. After some timeouts, Unbound retries with a smaller size, if applicable, or at size 1232 for IPv6 and 1472 for IPv4. This does not cause any negative effects due to the "flag day" [DNSFlagDay2020] change to 1232. --> 14) <!--[rfced] May we update this sentence as follows for clarity? Original: Unbound has minimal responses as an option, default on. Perhaps: Unbound has the 'minimal responses' configuration option; set default on. --> 15) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in fixed-width font. In the txt output, there are no changes to the font, and the quotation marks have been removed. Please review carefully and let us know if the output is acceptable or if any updates are needed. --> 16) <!-- [rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Don't Fragment flag (DF) bit vs. Don't Fragment (DF) bit [Note: Should this be "Don't Fragment (DF) flag bit" per RFC 0791?] More Fragments (MF) bit [Note: Should this be "More Fragments (MF) flag bit" for consistency?] b) We made the following updates for consistency. Please let us know of any objections. Additional Section -> Additional section (per RFCs 1035 and 9460) [Note: RFC 2782 uses "Additional Data section"; please let us know if the current text is okay or if it should include "data".] Path MTU discovery -> Path MTU Discovery (per RFC 8201) Path MTU -> path MTU (per RFC 8201) --> 17) <!-- [rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Elliptic Curve Digital Signature Algorithm (ECDSA) Edwards-curve Digital Signature Algorithm (EdDSA) Service Binding (SVCB) Resource Record (RR) b) We notice that this document as well as RFCs 8900 and 9471 use "EDNS0" but RFC 6891 uses "EDNS(0)". Please let us know if using "EDNS0" is preferred or if you would like to use "EDNS(0)". Current: Extension Mechanisms for DNS (EDNS0) Perhaps: Extension Mechanisms for DNS (EDNS(0)) c) We do not see "XDP" used in any other RFCs. Does "XDP" stand for something (i.e., can it be expanded)? Current: Fragments are ignored if they arrive over an XDP interface. --> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/kc On Jan 13, 2025, at 6:41 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/01/13 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9715.xml https://www.rfc-editor.org/authors/rfc9715.html https://www.rfc-editor.org/authors/rfc9715.pdf https://www.rfc-editor.org/authors/rfc9715.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9715-diff.html https://www.rfc-editor.org/authors/rfc9715-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9715-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9715 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9715 (draft-ietf-dnsop-avoid-fragmentation-20) Title : IP Fragmentation Avoidance in DNS over UDP Author(s) : K. Fujiwara, P. Vixie WG Chair(s) : Suzanne Woolf, Benno Overeinder, Tim Wicinski Area Director(s) : Warren Kumari, Mahesh Jethanandani -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
