Dear RFC Editor Karen, AD Warren, dnsop chairs, co-author Paul, Thanks very much.
-- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Karen Moore <kmo...@staff.rfc-editor.org> > Dear Kazunori, > > We have noted your approval on the AUTH48 status page for this document > (https://www.rfc-editor.org/authors/rfc9715-diff.html). > > We now have all of the necessary approvals and will move this document > forward in the publication process. > > Thank you to all for your time! > > Best regards, > RFC Editor/kc > >> On Jan 23, 2025, at 12:31 AM, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: >> >> Dear RFC Editor, >> >> This revision is OK for me. >> Please proceed. >> >> -- >> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >> >>> From: Karen Moore <kmo...@staff.rfc-editor.org> >>> Dear Paul, >>> >>> Thank you for your reply. We believe that this signifies your approval of >>> the document, so we have marked your approval on the AUTH48 status page >>> (https://www.rfc-editor.org/auth48/rfc9715). If that is not correct and you >>> need more time for review, please let us know. >>> >>> We now await approval from Kazunori prior to moving forward with the >>> publication process. >>> >>> Best regards, >>> RFC Editor/kc >>> >>>> On Jan 22, 2025, at 12:21 PM, p...@redbarn.org wrote: >>>> >>>> Nothing from me. >>>> >>>> Sent from Workspace ONE Boxer >>>> >>>> On Jan 22, 2025 11:01, Karen Moore <kmo...@staff.rfc-editor.org> wrote: >>>> Hi Warren, >>>> >>>> Thank you for your quick reply. We have noted your approval on the AUTH48 >>>> status page for this document (https://www.rfc-editor.org/auth48/rfc9715). >>>> >>>> We now await approvals (or further updates if needed) from Kazunori and >>>> Paul. >>>> >>>> Best regards, >>>> RFC Editor/kc >>>> >>>>> On Jan 22, 2025, at 10:40 AM, Warren Kumari <war...@kumari.net> wrote: >>>>> >>>>> On Tue, Jan 21, 2025 at 6:05 PM, Karen Moore >>>>> <kmo...@staff.rfc-editor.org> wrote: >>>>> Dear Kazunori and *Warren (AD), >>>>> >>>>> We have made your suggested update (see Appendix C.1). Please review the >>>>> updated file and let us know if any further changes are needed or if you >>>>> approve the document in its current form. >>>>> >>>>> *Warren, please review the following update (removal of text) and let us >>>>> know if you approve. The change is highlighted below and can also be >>>>> viewed here: https://www.rfc-editor.org/authors/rfc9715-auth48diff.html. >>>>> >>>>> Yes, thank you, I approve. >>>>> >>>>> W >>>>> >>>>> >>>>> OLD: >>>>> For R5, BIND 9 uses the edns-buf-size option, with the default of 1232. >>>>> >>>>> BIND 9 does implement R6. >>>>> >>>>> For R7, after two UDP timeouts, BIND 9 will fall back to TCP. >>>>> >>>>> >>>>> NEW: >>>>> For R5, BIND 9 uses the edns-buf-size option, with the default of 1232. >>>>> >>>>> For R7, after two UDP timeouts, BIND 9 will fall back to TCP. >>>>> >>>>> —Files (please refresh)— >>>>> >>>>> >>>>> 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 >>>>> >>>>> These diff files show only the changes made during the last edit round: >>>>> https://www.rfc-editor.org/authors/rfc9715-lastdiff.html >>>>> https://www.rfc-editor.org/authors/rfc9715-lastrfcdiff.html (side by >>>>> side) >>>>> >>>>> >>>>> This diff file shows all changes made to date: >>>>> https://www.rfc-editor.org/authors/rfc9715-diff.html >>>>> >>>>> >>>>> Best regards, >>>>> RFC Editor/kc >>>>> >>>>> On Jan 21, 2025, at 12:54 AM, Kazunori Fujiwara <fujiw...@jprs.co.jp> >>>>> wrote: >>>>> >>>>> Dear RFC Editor, >>>>> >>>>> >>>>> Current version is almost OK for me. >>>>> I would like to make an edit to remove one line. >>>>> >>>>> >>>>> Please remove a line at Appendix C.1. >>>>> Current: BIND 9 does implement R6 (Section 3.2). >>>>> >>>>> I attach edited XML file. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> -- >>>>> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >>>>> >>>>> From: Karen Moore <kmo...@staff.rfc-editor.org> 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 >>>>> >>>>> <?xml version='1.0' encoding='UTF-8'?> >>>>> >>>>> >>>>> <!-- pre-edited by ST 10/01/24 --> >>>>> <!-- formatted by ST 11/08/24 --> >>>>> <!-- reference review by TH 11/25/24 --> >>>>> >>>>> >>>>> <!DOCTYPE rfc [ >>>>> <!ENTITY nbsp " "> >>>>> <!ENTITY zwsp "​"> >>>>> <!ENTITY nbhy "‑"> >>>>> <!ENTITY wj "⁠"> >>>>> ]> >>>>> >>>>> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"; ipr="trust200902" >>>>> docName="draft-ietf-dnsop-avoid-fragmentation-20" number="9715" >>>>> category="info" consensus="true" submissionType="IETF" tocDepth="4" >>>>> tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" updates="" >>>>> version="3" xml:lang="en"> >>>>> >>>>> >>>>> <front> >>>>> <title abbrev="Avoid IP Fragmentation">IP Fragmentation Avoidance in DNS >>>>> over UDP</title> >>>>> <seriesInfo name="RFC" value="9715"/> >>>>> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara"> >>>>> <organization abbrev="JPRS">Japan Registry Services Co., >>>>> Ltd.</organization> >>>>> <address> >>>>> <postal> >>>>> <street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street> >>>>> <region>Chiyoda-ku, Tokyo</region> >>>>> <code>101-0065</code> >>>>> <country>Japan</country> >>>>> </postal> >>>>> <phone>+81 3 5215 8451</phone> >>>>> <email>fujiw...@jprs.co.jp</email> >>>>> </address> >>>>> </author> >>>>> <author initials="P." surname="Vixie" fullname="Paul Vixie"> >>>>> <organization>AWS Security</organization> >>>>> <address> >>>>> <postal> >>>>> <street>11400 La Honda Road</street> >>>>> <city>Woodside</city> >>>>> <region>CA</region> >>>>> <code>94062</code> >>>>> <country>United States of America</country> >>>>> </postal> >>>>> <phone>+1 650 393 3994</phone> >>>>> <email>p...@redbarn.org</email> >>>>> </address> >>>>> </author> >>>>> <date year="2025" month="January"/> >>>>> <area>OPS</area> >>>>> <workgroup>dnsop</workgroup> >>>>> >>>>> >>>>> <abstract> >>>>> <t>The widely >>>>> deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS >>>>> enables a DNS receiver to indicate its received UDP message size >>>>> capacity, which supports the sending of large UDP responses by a DNS >>>>> server. >>>>> Large DNS/UDP messages are more likely to be fragmented, and IP >>>>> fragmentation has exposed weaknesses in application protocols. It is >>>>> possible to avoid IP fragmentation in DNS by limiting the response size >>>>> where possible and signaling the need to upgrade from UDP to TCP >>>>> transport where necessary. >>>>> This document describes techniques to avoid IP fragmentation in DNS.</t> >>>>> </abstract> >>>>> </front> >>>>> <middle> >>>>> <?line 142?> >>>>> >>>>> >>>>> <section anchor="introduction"> >>>>> <name>Introduction</name> >>>>> <t>This document was originally intended to be a Best Current Practice, >>>>> but due to operating system and socket option limitations, some of the >>>>> recommendations have not yet gained real-world experience; therefore, >>>>> this document is Informational. >>>>> It is expected that, as operating systems and implementations evolve, we >>>>> will gain more experience with the recommendations and will publish an >>>>> updated document as a Best Current Practice in the future.</t> >>>>> <t>DNS has an EDNS(0) mechanism <xref target="RFC6891"/>. The widely >>>>> deployed EDNS(0) feature in the DNS enables a DNS receiver to indicate >>>>> its received UDP message size capacity, which supports the sending of >>>>> large UDP responses by a DNS server. >>>>> DNS over UDP invites IP fragmentation when a packet is larger than the >>>>> Maximum Transmission Unit (MTU) of some network in the packet's path.</t> >>>>> <t>Fragmented DNS UDP responses have systemic weaknesses, which expose >>>>> the requestor to DNS cache poisoning from off-path attackers (see <xref >>>>> target="ProblemOfFragmentation"/> for references and details).</t> >>>>> <t><xref target="RFC8900"/> states that IP fragmentation introduces >>>>> fragility to Internet communication. >>>>> The transport of DNS messages >>>>> over UDP should take account of the observations stated in that >>>>> document.</t> >>>>> <t>TCP avoids fragmentation by segmenting data into packets that are >>>>> smaller than or equal to the Maximum Segment Size (MSS). 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. This takes advantage of the elasticity of the TCP's packetizing >>>>> process, depending on how much queued data will fit into the next >>>>> segment. In contrast, DNS over UDP has little datagram size elasticity >>>>> and lacks insight into IP header and option size, so we must make more >>>>> conservative estimates about available UDP payload space.</t> >>>>> <t><xref target="RFC7766"/> states that all general-purpose DNS >>>>> implementations <bcp14>MUST</bcp14> support both UDP and TCP >>>>> transport.</t> >>>>> >>>>> >>>>> <t>DNS transaction security <xref target="RFC8945"/> <xref >>>>> target="RFC2931"/> does protect against the security risks of >>>>> fragmentation, and it protects delegation responses. But <xref >>>>> target="RFC8945"/> has limited applicability due to key distribution >>>>> requirements, and there is little if any deployment of <xref >>>>> target="RFC2931"/>.</t> >>>>> <t>This document describes various techniques to avoid IP fragmentation >>>>> of UDP packets in DNS. >>>>> This document is primarily applicable to DNS use on the global >>>>> Internet.</t> >>>>> <t>In contrast, a path MTU that deviates from the recommended value might >>>>> be obtained through static configuration, server routing hints, or a >>>>> future discovery protocol. However, addressing this falls outside the >>>>> scope of this document and may be the subject of future >>>>> specifications.</t> >>>>> </section> >>>>> <section anchor="terminology"> >>>>> <name>Terminology</name> >>>>> <t> >>>>> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", >>>>> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL >>>>> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", >>>>> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", >>>>> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are >>>>> to be interpreted as described in BCP 14 <xref target="RFC2119"/> >>>>> <xref target="RFC8174"/> when, and only when, they appear in all >>>>> capitals, as shown here. >>>>> </t> >>>>> >>>>> <t>The definitions of "requestor" and "responder" are per <xref >>>>> target="RFC6891"/>:</t> >>>>> >>>>> >>>>> <blockquote> >>>>> "Requestor" refers to the side that sends a request. "Responder" refers >>>>> to an authoritative, recursive resolver or other DNS component that >>>>> responds to questions.</blockquote> >>>>> >>>>> >>>>> <t>The definition of "path MTU" is per <xref target="RFC8201"/>:</t> >>>>> <blockquote>path MTU [is] the minimum link MTU of all the links in a path >>>>> between a source node and a destination node.</blockquote> >>>>> >>>>> >>>>> <t>In this document, the term "Path MTU Discovery" includes both >>>>> Classical Path MTU Discovery <xref target="RFC1191"/> <xref >>>>> target="RFC8201"/> and Packetization Layer Path MTU Discovery <xref >>>>> target="RFC8899"/>.</t> >>>>> <t>Many of the specialized terms used in this document are defined in >>>>> "DNS Terminology" <xref target="RFC9499"/>.</t> >>>>> </section> >>>>> <section anchor="recommendation"> >>>>> <name>How to Avoid IP Fragmentation in DNS</name> >>>>> <t>These recommendations are intended >>>>> for nodes with global IP addresses on the Internet. Private networks or >>>>> local networks are out of the scope of this document.</t> >>>>> <t>The methods to avoid IP fragmentation in DNS are described below:</t> >>>>> <section anchor="RecommendationsResponders"> >>>>> <name>Proposed Recommendations for UDP Responders</name> <dl >>>>> spacing="normal" newline="false" indent="7"> >>>>> <dt>R1.</dt><dd>UDP responders should not use IPv6 fragmentation >>>>> <xref target="RFC8200"/>.</dd> >>>>> <dt>R2.</dt><dd><t>UDP responders should configure their systems to >>>>> prevent fragmentation of UDP packets when sending replies, provided it >>>>> can be done safely. The mechanisms to achieve this vary across different >>>>> operating systems.</t> >>>>> >>>>> >>>>> <t>For BSD-like operating systems, the IP Don't Fragment (DF) flag bit >>>>> <xref target="RFC0791"/> can be used to prevent fragmentation. In >>>>> contrast, Linux systems do not expose a direct API for this purpose and >>>>> require the use of Path MTU socket options >>>>> (IP_MTU_DISCOVER) to manage fragmentation settings. However, it is >>>>> important to note that enabling IPv4 Path MTU Discovery for UDP in >>>>> current Linux versions is considered harmful and dangerous. For more >>>>> details, see <xref target="impl"/>.</t></dd> >>>>> <dt>R3.</dt><dd>UDP responders should compose response packets that fit >>>>> in the minimum of the offered requestor's maximum UDP payload size <xref >>>>> target="RFC6891"/>, the interface MTU, the network MTU value configured >>>>> by the knowledge of the network operators, and the >>>>> <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. For more >>>>> details, see >>>>> <xref target="details"/>.</dd> >>>>> <dt>R4.</dt><dd>If the UDP responder detects an immediate error >>>>> indicating that the UDP packet exceeds the path MTU size, the UDP >>>>> responder may recreate response packets that fit in the path MTU size or >>>>> with the TC bit set.</dd> >>>>> </dl> >>>>> <t>The cause and effect of the TC bit are unchanged <xref >>>>> target="RFC1035"/>.</t> >>>>> </section> >>>>> <section anchor="RecommendationsRequestors"> >>>>> <name>Proposed Recommendations for UDP Requestors</name> <dl >>>>> spacing="normal" newline="false" indent="7"> >>>>> <dt>R5.</dt><dd>UDP requestors should limit the requestor's maximum UDP >>>>> payload size to fit in the minimum of the interface MTU, the network MTU >>>>> value configured by the network operators, and the >>>>> <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. A smaller >>>>> limit may be allowed. For more details, see <xref >>>>> target="details"/>.</dd> >>>>> >>>>> >>>>> <dt>R6.</dt><dd>UDP requestors should drop fragmented DNS/UDP responses >>>>> without IP reassembly to avoid cache poisoning attacks (at the firewall >>>>> function).</dd> >>>>> <dt>R7.</dt><dd>DNS responses may be dropped by IP fragmentation. It is >>>>> recommended that requestors eventually try alternative transport >>>>> protocols.</dd> </dl> >>>>> </section> >>>>> </section> >>>>> <section anchor="RecommendationOperators"> >>>>> <name>Proposed Recommendations for DNS Operators</name> >>>>> <t>Large DNS responses are typically the result of zone configuration. >>>>> People who publish information in the DNS should seek configurations >>>>> resulting in small responses. For example:</t> >>>>> <dl spacing="normal" newline="false" indent="7"> <dt>R8.</dt><dd>Use a >>>>> smaller number of name servers.</dd> <dt>R9.</dt><dd>Use a smaller number >>>>> of A/AAAA RRs for a domain name.</dd> <dt>R10.</dt><dd>Use >>>>> minimal-responses configuration: Some implementations have a 'minimal >>>>> responses' configuration option that causes DNS servers to make response >>>>> packets smaller by containing only mandatory and required data (<xref >>>>> target="minimal-responses"/>).</dd> <dt>R11.</dt><dd>Use a smaller >>>>> signature / public key size algorithm for DNSSEC. Notably, the signature >>>>> sizes of the Elliptic Curve Digital Signature Algorithm (ECDSA) and >>>>> Edwards-curve Digital Signature Algorithm (EdDSA) are smaller than those >>>>> of equivalent cryptographic strength using RSA.</dd> >>>>> </dl> >>>>> <t>It is difficult to determine a specific upper limit for R8, R9, and >>>>> R11, but it is sufficient if all responses from the DNS servers are below >>>>> the size of R3 and R5.</t> >>>>> </section> >>>>> <section anchor="protocol"> >>>>> <name>Protocol Compliance Considerations</name> >>>>> <t>Some authoritative servers deviate from the DNS standard as >>>>> follows:</t> >>>>> <ul spacing="normal"> >>>>> <li> >>>>> <t>Some authoritative servers ignore the EDNS(0) requestor's maximum UDP >>>>> payload size and return large UDP responses <xref >>>>> target="Fujiwara2018"/>.</t> >>>>> </li> >>>>> <li> >>>>> <t>Some authoritative servers do not support TCP transport.</t> >>>>> </li> >>>>> </ul> >>>>> <t>Such non-compliant behavior cannot become implementation or >>>>> configuration constraints for the rest of the DNS. If failure is the >>>>> result, then that failure must be localized to the non-compliant >>>>> servers.</t> >>>>> </section> >>>>> <section anchor="iana"> >>>>> <name>IANA Considerations</name> >>>>> <t>This document has no IANA actions.</t> >>>>> </section> >>>>> <section anchor="securitycons"> >>>>> <name>Security Considerations</name> >>>>> <section anchor="on-path-fragmentation-on-ipv4"> >>>>> <name>On-Path Fragmentation on IPv4</name> >>>>> <t>If the Don't Fragment (DF) flag bit is not set, on-path fragmentation >>>>> may happen on IPv4, >>>>> and it can lead to vulnerabilities as shown in <xref >>>>> target="ProblemOfFragmentation"/>. To avoid this, R6 needs to be used to >>>>> discard the fragmented responses and retry using TCP.</t> >>>>> </section> >>>>> <section anchor="small-mtu-network"> >>>>> <name>Small MTU Network</name> >>>>> <t>When avoiding fragmentation, >>>>> a DNS/UDP requestor behind a small MTU network may experience UDP >>>>> timeouts, which would reduce performance >>>>> and may lead to TCP fallback. >>>>> This would indicate prior reliance upon IP fragmentation, which is >>>>> considered to be harmful >>>>> to both the performance and stability of applications, endpoints, and >>>>> gateways. Avoiding IP fragmentation will improve operating conditions >>>>> overall, and the performance of DNS/TCP has increased and will continue >>>>> to increase.</t> >>>>> <t>If a UDP response packet is dropped in transit, up to and including >>>>> the network stack of the initiator, it increases the attack window for >>>>> poisoning the requestor's cache.</t> >>>>> </section> >>>>> <section anchor="ProblemOfFragmentation"> >>>>> <name>Weaknesses of IP Fragmentation</name> >>>>> <t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"/> >>>>> notes effective off-path DNS cache poisoning attack vectors using IP >>>>> fragmentation. >>>>> "IP fragmentation attack on DNS" <xref target="Hlavacek2013"/> and >>>>> "Domain Validation++ For MitM-Resilient PKI" <xref target="Brandt2018"/> >>>>> note that off-path attackers can intervene in the Path MTU Discovery >>>>> <xref target="RFC1191"/> to cause authoritative servers to produce >>>>> fragmented responses. >>>>> <xref target="RFC7739"/> states the security implications of predictable >>>>> fragment identification values.</t> >>>>> >>>>> >>>>> <t><xref section="3.2" sectionFormat="of" target="RFC8085"/> states that >>>>> "an application <bcp14>SHOULD NOT</bcp14> send UDP datagrams that result >>>>> in IP packets that exceed the Maximum Transmission Unit (MTU) along the >>>>> path to the destination".</t> >>>>> <t>A DNS message receiver cannot trust fragmented UDP datagrams primarily >>>>> due to the small amount of entropy provided by UDP port numbers and DNS >>>>> message identifiers, each of which is only 16 bits in size, and both are >>>>> likely to be in the first fragment of a packet if fragmentation occurs. >>>>> By comparison, the TCP protocol stack controls packet size and avoids IP >>>>> fragmentation under ICMP NEEDFRAG attacks. In TCP, fragmentation should >>>>> be avoided for performance reasons, whereas for UDP, fragmentation should >>>>> be avoided for resiliency and authenticity reasons.</t> >>>>> </section> >>>>> <section anchor="dns-security-protections"> >>>>> <name>DNS Security Protections</name> >>>>> <t>DNSSEC is a countermeasure against cache poisoning attacks that use IP >>>>> fragmentation. >>>>> However, DNS delegation responses are not signed with DNSSEC, and DNSSEC >>>>> does not have a mechanism to get the correct response if an incorrect >>>>> delegation is injected. This is a denial-of-service vulnerability that >>>>> can yield failed name resolutions. If cache poisoning attacks can be >>>>> avoided, >>>>> DNSSEC validation failures will be avoided.</t> >>>>> </section> >>>>> <section anchor="possible-actions-for-resolver-operators"> >>>>> <name>Possible Actions for Resolver Operators</name> >>>>> <t>Because this document is published as Informational rather than a Best >>>>> Current Practice, >>>>> this section presents steps that resolver operators can take to avoid >>>>> vulnerabilities related to IP fragmentation.</t> >>>>> <t>To avoid vulnerabilities related to IP fragmentation, implement R5 and >>>>> R6.</t> >>>>> >>>>> >>>>> <t>Specifically, configure the firewall functions protecting the >>>>> full-service resolver to discard incoming DNS response packets >>>>> with a non-zero Fragment Offset (FO) or a More Fragments (MF) flag bit of >>>>> 1 on IPv4, and discard packets with IPv6 Fragment Headers. >>>>> (If the resolver's IP address is not dedicated to the DNS resolver and >>>>> uses UDP communication that relies on IP Fragmentation for purposes other >>>>> than DNS, discard only the first fragment that contains the UDP header >>>>> from port 53.)</t> >>>>> <t>The most recent resolver software is believed to implement R7.</t> >>>>> <t>Even if R7 is not implemented, it will only result in a name >>>>> resolution error, preventing attacks from leading to malicious sites.</t> >>>>> </section> >>>>> </section> >>>>> </middle> >>>>> <back> >>>>> <references> >>>>> <name>References</name> >>>>> <references anchor="sec-normative-references"> >>>>> <name>Normative References</name> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7739.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/> >>>>> </references> >>>>> <references anchor="sec-informative-references"> >>>>> <name>Informative References</name> >>>>> >>>>> >>>>> <reference anchor="Brandt2018" >>>>> target="https://dl.acm.org/doi/10.1145/3243734.3243790";> >>>>> <front> >>>>> <title>Domain Validation++ For MitM-Resilient PKI</title> >>>>> <author initials="M." surname="Brandt" fullname="Markus Brandt"> >>>>> <organization>Fraunhofer Institute for Secure Information Technology SIT, >>>>> Darmstadt, Germany</organization> >>>>> </author> >>>>> <author initials="T." surname="Dai" fullname="Tianxiang Dai"> >>>>> <organization>Fraunhofer Institute for Secure Information Technology SIT, >>>>> Darmstadt, Germany</organization> >>>>> </author> >>>>> <author initials="A." surname="Klein" fullname="Amit Klein"> >>>>> <organization>Fraunhofer Institute for Secure Information Technology SIT, >>>>> Darmstadt, Germany</organization> >>>>> </author> >>>>> <author initials="H." surname="Shulman" fullname="Haya Shulman"> >>>>> <organization>Fraunhofer Institute for Secure Information Technology SIT, >>>>> Darmstadt, Germany</organization> >>>>> </author> >>>>> <author initials="M." surname="Waidner" fullname="Michael Waidner"> >>>>> <organization>Fraunhofer Institute for Secure Information Technology SIT, >>>>> Darmstadt, Germany</organization> >>>>> </author> >>>>> <date month="October" year="2018"/> >>>>> </front> >>>>> <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer and >>>>> Communications Security, pp. 2060-2076</refcontent> <seriesInfo >>>>> name="DOI" value="10.1145/3243734.3243790"/> >>>>> </reference> >>>>> >>>>> >>>>> <reference anchor="Herzberg2013" >>>>> target="https://ieeexplore.ieee.org/document/6682711";> >>>>> <front> >>>>> <title>Fragmentation Considered Poisonous, or: >>>>> One-domain-to-rule-them-all.org</title> >>>>> <author initials="A." surname="Herzberg" fullname="Amir Herzberg"> >>>>> <organization/> >>>>> </author> >>>>> <author initials="H." surname="Shulman" fullname="Haya Shulman"> >>>>> <organization/> >>>>> </author> >>>>> <date year="2013"/> >>>>> </front> >>>>> <refcontent>IEEE Conference on Communications and Network Security >>>>> (CNS)</refcontent> <seriesInfo name="DOI" >>>>> value="10.1109/CNS.2013.6682711"/> >>>>> </reference> >>>>> >>>>> >>>>> <reference anchor="Hlavacek2013" >>>>> target="https://ripe67.ripe.net/presentations/240-ipfragattack.pdf";> >>>>> <front> >>>>> <title>IP fragmentation attack on DNS</title> >>>>> <author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek"> >>>>> <organization>cz.nic</organization> >>>>> </author> >>>>> <date year="2013"/> >>>>> </front> >>>>> <refcontent>RIPE 67 Meeting</refcontent> >>>>> </reference> >>>>> >>>>> >>>>> <reference anchor="Fujiwara2018" >>>>> target="https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf";> >>>>> >>>>> <front> >>>>> <title>Measures against DNS cache poisoning attacks using IP >>>>> fragmentation</title> >>>>> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara"> >>>>> <organization>JPRS</organization> >>>>> </author> >>>>> <date year="2019"/> >>>>> </front> >>>>> <refcontent>OARC 30 Workshop</refcontent> >>>>> </reference> >>>>> >>>>> >>>>> <reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/";> >>>>> <front> >>>>> <title>DNS flag day 2020</title> >>>>> <author> >>>>> <organization/> >>>>> </author> >>>>> <date></date> >>>>> </front> >>>>> </reference> >>>>> >>>>> >>>>> <reference anchor="Huston2021" >>>>> target="https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf";> >>>>> >>>>> <front> >>>>> <title>Measuring DNS Flag Day 2020</title> >>>>> <author initials="G." surname="Huston" fullname="Geoff Huston"> >>>>> <organization>APNIC Labs</organization> >>>>> </author> >>>>> <author initials="J." surname="Damas" fullname="Joao Damas"> >>>>> <organization>APNIC Labs</organization> >>>>> </author> >>>>> <date year="2021" month="February"/> >>>>> </front> >>>>> <refcontent>OARC 34 Workshop</refcontent> >>>>> </reference> >>>>> >>>>> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9471.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/> >>>>> <xi:include >>>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2671.xml"/> >>>>> >>>>> >>>>> </references> >>>>> </references> >>>>> >>>>> >>>>> <section anchor="details"> >>>>> <name>Details of Requestor's Maximum UDP Payload Size Discussions</name> >>>>> <t>There are many discussions about default path MTU size and a >>>>> requestor's maximum UDP payload size.</t> >>>>> <ul spacing="normal"> >>>>> <li> >>>>> <t>The minimum MTU for an IPv6 interface is 1280 octets >>>>> (see <xref section="5" sectionFormat="of" target="RFC8200"/>). So, it can >>>>> be used as the default path MTU value for IPv6. The corresponding minimum >>>>> MTU for an IPv4 interface is 68 (60 + 8) >>>>> <xref target="RFC0791"/>.</t> >>>>> </li> >>>>> <li> >>>>> >>>>> >>>>> <t><xref target="RFC4035"/> states that "A security-aware name server >>>>> <bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) message >>>>> size extension, [and it] <bcp14>MUST</bcp14> support a message size of at >>>>> least 1220 octets". Then, the smallest number of the maximum DNS/UDP >>>>> payload size is 1220.</t> >>>>> </li> >>>>> <li> >>>>> <t>In order to avoid IP fragmentation, >>>>> <xref target="DNSFlagDay2020"/> proposes that UDP requestors set the >>>>> requestor's payload size to 1232 and UDP responders compose UDP responses >>>>> so they fit in 1232 octets. >>>>> The size 1232 is based on an MTU of 1280, which is required by the IPv6 >>>>> specification <xref target="RFC8200"/>, minus 48 octets for the IPv6 and >>>>> UDP headers.</t> >>>>> </li> >>>>> <li> >>>>> <t>Most of the Internet, especially the inner core, has an MTU of at >>>>> least 1500 octets. >>>>> Maximum DNS/UDP payload size for IPv6 on an MTU 1500 Ethernet is 1452 >>>>> (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)). To allow >>>>> for possible IP options and distant tunnel overhead, the recommendation >>>>> of default maximum DNS/UDP payload size is 1400.</t> >>>>> </li> >>>>> <li> >>>>> <t><xref target="Huston2021"/> analyzes the result of <xref >>>>> target="DNSFlagDay2020"/> and reports that their measurements suggest >>>>> that in the interior of the Internet between recursive resolvers and >>>>> authoritative servers, the prevailing MTU is 1500 and there is no >>>>> measurable signal of use of smaller MTUs in this part of the Internet. >>>>> They propose that >>>>> their measurements suggest setting the EDNS(0) requestor's UDP payload >>>>> size to 1472 octets for IPv4 and 1452 octets for IPv6.</t> >>>>> </li> >>>>> </ul> >>>>> <t>As a result of these discussions, >>>>> this document recommends a value of 1400, >>>>> with smaller values also allowed.</t> >>>>> </section> >>>>> <section anchor="minimal-responses"> >>>>> <name>Minimal Responses</name> >>>>> <t>Some implementations have a "minimal responses" configuration >>>>> setting/option that causes a DNS server to make response packets smaller, >>>>> containing only mandatory and required data.</t> >>>>> >>>>> >>>>> <t>Under the minimal-responses configuration, a DNS server composes >>>>> responses containing only necessary Resource Records (RRs). For >>>>> delegations, see <xref target="RFC9471"/>. In case of a non-existent >>>>> domain name or non-existent type, the authority section will contain an >>>>> SOA record, and the answer section is empty >>>>> (see <xref section="2" sectionFormat="of" target="RFC2308"/>).</t> >>>>> <t>Some resource records (MX, SRV, SVCB, and HTTPS) require additional A, >>>>> AAAA, and Service Binding (SVCB) records in the Additional section >>>>> defined in <xref target="RFC1035"/>, <xref target="RFC2782"/>, and <xref >>>>> target="RFC9460"/>.</t> >>>>> <t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC >>>>> OK bit, signatures are added in the answer section, >>>>> or the corresponding DS RRSet and signatures are added in the authority >>>>> section. Details are defined in <xref target="RFC4035"/> and <xref >>>>> target="RFC5155"/>.</t> >>>>> </section> >>>>> <section anchor="impl"> >>>>> <name>Known Implementations</name> >>>>> >>>>> >>>>> <t>This section records the status of known implementations of the >>>>> proposed recommendations described in <xref >>>>> target="recommendation"/>.</t> >>>>> <t>Please note that the listing of any individual implementation here >>>>> does not imply endorsement by the IETF. Furthermore, no effort has been >>>>> made to verify the information that was supplied by IETF contributors and >>>>> presented here.</t> >>>>> <section anchor="bind-9"> >>>>> >>>>> >>>>> <name>BIND 9</name> >>>>> <t>BIND 9 does not implement R1 and R2. <!--<xref >>>>> target="RecommendationsResponders"/>--></t> >>>>> <t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a >>>>> fallback to IP_PMTUDISC_DONT.</t> >>>>> >>>>> >>>>> <t>When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), >>>>> IP_DONTFRAG is disabled.</t> >>>>> <t>Accepting Path MTU Discovery for UDP is considered harmful and >>>>> dangerous. BIND 9's settings avoid attacks to Path MTU Discovery.</t> >>>>> <t>For R3, BIND 9 will honor the requestor's size up to the configured >>>>> limit (<tt>max-udp-size</tt>). The UDP response packet is bound to be >>>>> between 512 and 4096 bytes, with the default set to 1232. BIND 9 supports >>>>> the requestor's size up to the configured limit >>>>> (<tt>max-udp-size</tt>).</t> >>>>> <t>In the case of R4 and the send fails with EMSGSIZE, BIND 9 sets the TC >>>>> bit and tries to send a minimal answer again.</t> >>>>> <t>For R5, <!--<xref target="RecommendationsRequestors"/>--> BIND 9 uses >>>>> the <tt>edns-buf-size</tt> option, with the default of 1232.</t> >>>>> <!-- remove this (by fujiwara): <t>BIND 9 does implement R6.--> <!--<xref >>>>> target="RecommendationsRequestors"/>--><!-- </t> --> >>>>> <t>For R7, after two UDP timeouts, BIND 9 will fall back to TCP.</t> >>>>> </section> >>>>> <section anchor="knot-dns-and-knot-resolver"> >>>>> <name>Knot DNS and Knot Resolver</name> >>>>> <t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. The >>>>> UDP size limit is 1232 by default.</t> >>>>> <t>Fragments are ignored if they arrive over a Linux XDP interface.</t> >>>>> <t>TCP is attempted after repeated UDP timeouts.</t> >>>>> <t>Minimal responses are returned and are currently not configurable.</t> >>>>> <t>Smaller signatures are used, with ecdsap256sha256 as the default.</t> >>>>> </section> >>>>> <section >>>>> anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdist"> >>>>> >>>>> <name>PowerDNS Authoritative Server, PowerDNS Recursor, and PowerDNS >>>>> dnsdist</name> >>>>> >>>>> >>>>> <ul spacing="normal"> >>>>> <li> >>>>> <t>Use IP_PMTUDISC_OMIT with a fallback to IP_PMTUDISC_DONT.</t> >>>>> </li> >>>>> <li> >>>>> <t>The default EDNS buffer size of 1232; no probing for smaller >>>>> sizes.</t> >>>>> </li> >>>>> <li> >>>>> <t>There is no handling of EMSGSIZE.</t> >>>>> </li> >>>>> <li> >>>>> <t>Recursor: UDP timeouts do not cause a switch to TCP, but "spoofing >>>>> near misses" may.</t> >>>>> </li> >>>>> </ul> >>>>> </section> >>>>> <section anchor="powerdns-authoritative-server"> >>>>> <name>PowerDNS Authoritative Server</name> >>>>> <ul spacing="normal"> >>>>> <li> >>>>> <t>The default DNSSEC algorithm is 13.</t> >>>>> </li> >>>>> <li> >>>>> <t>Responses are minimal; this is not configurable.</t> >>>>> </li> >>>>> </ul> >>>>> </section> >>>>> <section anchor="unbound"> >>>>> <name>Unbound</name> >>>>> <t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to >>>>> IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have it, >>>>> but not on Apple systems. On systems that support it, Unbound sets >>>>> IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback to >>>>> IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT, with >>>>> a fallback to IPV6_PMTUDISC_DONT.</t> >>>>> <t>Unbound requests a UDP size of 1232 from peers, by default. The >>>>> requestor's size is limited to a max of 1232.</t> >>>>> >>>>> <t>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" <xref >>>>> target="DNSFlagDay2020"/> change to 1232.</t> >>>>> >>>>> >>>>> <t>Unbound has the "minimal responses" configuration option; set default >>>>> on.</t> >>>>> </section> >>>>> <section anchor="acknowledgments" numbered="false"> >>>>> <name>Acknowledgments</name> >>>>> <t>The authors would like to specifically thank <contact fullname="Paul >>>>> Wouters"/>, <contact fullname="Mukund Sivaraman"/>, <contact >>>>> fullname="Tony Finch"/>, <contact fullname="Hugo Salgado"/>, <contact >>>>> fullname="Peter van Dijk"/>, <contact fullname="Brian Dickson"/>, >>>>> <contact fullname="Puneet Sood"/>, <contact fullname="Jim Reid"/>, >>>>> <contact fullname="Petr Spacek"/>, <contact fullname="Andrew >>>>> McConachie"/>, <contact fullname="Joe Abley"/>, <contact >>>>> fullname="Daisuke Higashi"/>, <contact fullname="Joe Touch"/>, <contact >>>>> fullname="Wouter Wijngaards"/>, <contact fullname="Vladimir Cunat"/>, >>>>> <contact fullname="Benno Overeinder"/>, and <contact fullname="Štěpán >>>>> Němec"/> for their extensive reviews and comments.</t> >>>>> </section> >>>>> </section> >>>>> </back> >>>>> >>>>> <!-- [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. >>>>> --> >>>>> >>>>> </rfc> >>>>> >>>> >>>> >>> >>> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
