Dear Kazunori and Paul, Thank you for your replies. We have updated our files based on your feedback. Note that we updated “EDNS0” to “EDNS(0)”and the recommendation numbers to reflect “R#”. Please review the changes (especially Appendix C.1 to ensure we updated the text as desired), and let us know if any further updates are needed or if you approve the document in its current form.
—Files— The updated XML file is here: https://www.rfc-editor.org/authors/rfc9715.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9715.txt https://www.rfc-editor.org/authors/rfc9715.pdf https://www.rfc-editor.org/authors/rfc9715.html This diff file shows all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9715-auth48diff.html This diff file shows all changes made to date: https://www.rfc-editor.org/authors/rfc9715-diff.html Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. We will await approvals from each author prior to moving forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9715 Thank you, RFC Editor/kc > On Jan 16, 2025, at 2:20 AM, Kazunori Fujiwara via auth48archive > <auth48archive@rfc-editor.org> wrote: > > Dear RFC Editor, > > Thanks very much for your excellent rewrites. > > I will answer in-line as a first, quick response to proceed. > >> From: rfc-edi...@rfc-editor.org >> 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 >> --> > > Agree. > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > I think "DNS" and "IP Fragmentation" are key words. > > Some RFCs that show attack countermeasures include "attack". > >> 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. >> --> > > The proposed text is roughly fine, but I think it would be better to > delete "of the segment" from "the MSS of the other end of the > 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. >> --> > > Agree. > >> 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). >> --> > > This draft is "Informational". Then, ideally, please change to "should". > >> 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". >> --> > > Agree. > >> 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> >> --> > > I agree all fixes. > >> 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". >> --> > > Agree. > >> 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. >> --> > > This document was changed from BCP to Informational due to > implementation concerns. I would like to keep Appendix C since it is > relevant in this situation. > >> 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. >> --> > > This part remains the same as when the intended status was BCP. > It is an oversight. > > Please change "best practices defined by this specification" > as "proposed recommendations described in Section 3". > >> 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. > > Authors intended R# to be unique and consistent in the document. > However, part of Appendix C were forgotten to be updated. > We need to refer draft-ietf-dnsop-avoid-fragmentation-12, > "Appendix D. Known Implementations" first appeared. > >> 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? > > Since R# is unique, the section number may not be necessary. > >> 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. > ^^^^^^^^^^^^^^^remove > >> For R3 (Section 3.1), BIND 9 will honor the requestor's size up to > ^^^^^^^^^^^^^remove >> the configured limit (max-udp-size)... >> >> In the case of R4 (Section 3.1) and the send fails with EMSGSIZE, > ^^^^^^^^^^^^^remove >> 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 > ^^^^^^^^^^^^^remove >> option, with the default of 1232. >> >> BIND 9 does implement R6 (Section 3.2). > ^^^^^^^^^^^^^ remove >> For R7 (Section 3.2), after two UDP timeouts, BIND 9 will fall back > ^^^^^^^^^^^^^remove >> 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. >> --> > > Agree. > >> 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. >> --> > > Agree. > >> 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. >> --> > > Agree. > >> 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. >> --> > > Agree. > >> 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. >> --> > > I will check this next revision. > >> 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?] > > Yes. Please choose RFC 0791 style. > >> 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) >> --> > > Agree. > >> 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) > > OK for me. > >> 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)) > > Both are OK for me. > need to discuss with co-author. > >> 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. >> --> > > This section contains verbatim text from each implementer, > so there may be some inconsistencies in the text. > Regarding XDP, how about "Linux XDP" ? > >> 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. >> --> > > I will need to work next weeks... > But now, I could not retrieve NIST document now. > https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf > -> 503 Service Unavailable > > > Regards, > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > > >> 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
