DNSOP C. Heard Internet Draft Unaffiliated Intended status: Experimental April 28, 2024 Expires: October 2024 Use of UDP Options for Transmission of Large DNS Responses draft-heard-dnsop-udp-opt-large-dns-responses-00.txt Abstract This document describes an experimental method for using UDP Options to facilitate the transmission of large DNS responses without the use of IP fragmentation or fallback to TCP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 28, 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Heard Expires October 28, 2024 [Page 1] Internet-Draft UDP Options for Large DNS Responses April 2024 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. Terminology....................................................2 4. Background.....................................................3 5. Proposed Use of UDP Options in DNS Requests and Responses......4 6. Discussion.....................................................5 7. Security Considerations........................................5 8. IANA Considerations............................................6 9. References.....................................................6 9.1. Normative References......................................6 9.2. Informative References....................................7 10. Acknowledgments...............................................7 1. Introduction This document describes an experimental method for using UDP Options [To24] to facilitate the transmission of large DNS responses without the use of IP fragmentation or fallback to TCP. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In this document, the characters ">>" preceding an indented line(s) indicates a statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the portions of this RFC covered by these key words. 3. Terminology The following terminology is used in this document: Heard Expires October 28, 2024 [Page 2] Internet-Draft UDP Options for Large DNS Responses April 2024 o "Requestor" refers to the side that sends a DNS request. "Responder" refers to an authoritative server, recursive resolver, or other DNS component that responds to questions. (Quoted from [RFC6891]) o "Link MTU" is the maximum transmission unit (i.e., the maximum packet size in octets) that can be conveyed over a link. (Quoted from [RFC8200]) o "Path MTU" is the minimum link MTU of all the links in a path between a source node and a destination node. (Quoted from [RFC8200]) 4. Background Large DNS/UDP responses, for instance those containing DNSSEC [RFC4035] signatures, often require the use of IP fragmentation when transmitted over UDP. This is often viewed as undesirable, as IPv4 fragmentation [RFC791] has been observed to expose a requestor to off-path cache poisoning attacks [He12][Hl13], and IPv6 fragmentation [RFC8200] has been observed to be unreliable in real- world networks [Hu24]. For these reasons, [Fu24] recommends that responses be limited to a size that will not result in IP fragmentation. The key requirements levied by [Fu24] on DNS/UDP requestors and responders to achieve that goal are: o Requestors should limit the EDNS(0) maximum UDP payload size [RFC6891] that they indicate to 1400 bytes or less. o Responders should compose response packets that fit in the minimum of the offered requestor's maximum UDP payload size, the first-hop link MTU, the path MTU to the requestor (if known), and the recommended maximum DNS/UDP payload size 1400 bytes. If a complete response will not fit within the above limits, the responder should truncate the response and set the TC bit [RFC1035]. This serves as signal to the requestor to retry the query using TCP [RFC7766]. UDP Options [To24] extends UDP [RFC768] by adding transport options that reside within the hitherto-unused surplus area between the end of the UDP user data but before the end of the IP payload data. Two of the options defined therein, FRAG (fragmentation) and MRDS (maximum reassembled datagram size), can be used to avoid the fallback to TCP when a DNS response exceeds the maximum size recommended for an unfragmented UDP datagram. Specifically, FRAG can be used by an options-aware responder to transmit datagrams that Heard Expires October 28, 2024 [Page 3] Internet-Draft UDP Options for Large DNS Responses April 2024 are fragmented at the UDP layer, and MRDS can be used by an options- aware requestor to signal to a responder that it is able to reassemble datagrams of a specific size that are fragmented at the UDP layer. 5. Proposed Use of UDP Options in DNS Requests and Responses The protocol extensions proposed in this document are OPTIONAL for DNS/UDP requestors and responders. Nodes that choose to implement them MUST support the mandatory parts of the UDP Options specification [To24] and must also support the requirements of [Fu24] that are summarized in Section 4. The following requirements are specific to these protocol extensions. >> In addition to limiting the EDNS(0) maximum UDP payload size [to 1400 bytes, option-aware requestors SHOULD also include an instance of the MRDS option with MRDS size set to the size of the largest UDP packet that they are willing to reassemble from UDP fragments. >> Option-aware responders SHOULD compose response packets, not using UDP fragmentation, that fit in the minimum of the offered requestor's maximum UDP payload size, the first-hop link MTU, the path MTU to the requestor (if known), and the recommended maximum DNS/UDP payload size 1400 bytes. If a response will not fit within that size but will fit within the MRDS size transmitted in the corresponding request (assuming that the MRDS option was present), then the responder SHOULD send a response using UDP fragmentation as described in [To24]. If the response will not fit within either limit, then the responder MUST send a truncated response, not using UDP options, as specified in [RFC1035]. >> Some Internet paths may block all UDP options [Zu20]. Thus, if an option-aware requestor sends a request with the MRDS option and receives no response, it MUST fall back to sending the request with no UDP options, and it MUST refrain from sending additional requests with UDP options to the same destination IP address for a period of time. The specific timeout, number of retries, and the period of time for which IP options are embargoed in outgoing requests are left for the implementation to determine. It should be noted that the MRDS size includes the UDP header and any UDP options. Those sizes must be subtracted to determine the maximum DNS message size that can be sent using UDP fragmentation. Heard Expires October 28, 2024 [Page 4] Internet-Draft UDP Options for Large DNS Responses April 2024 6. Discussion The protocol extensions proposed in this document should be incrementally deployable, since DNS/UDP requestors and responders that participate in the proposed experiment are expected to interoperate seamlessly with those that do not. Option-aware responders will not use UDP fragmentation unless the requestor indicates, by sending the MRDS option, that responses using UDP fragmentation are acceptable. Option-aware requestors may include the MRDS option in packets sent to non-option-aware responders, but all endpoint implementations examined during the development of [To24] were found to ignore the surplus area between the end of the UDP user data but before the end of the IP payload data. The main obstacles to success of the proposed experiment are expected to be the rate of uptake of the UDP Options specification and the probability that UDP options will be blocked by middleboxes between the DNS/UDP requestor and the DNS/UDP responder. At present, the only known implementations of UDP Options are pre- standard experimental implementations that do not include all mandatory features, in particular UDP fragmentation and reassembly. It is hard to predict whether UDP Options will achieve significant production uptake in the real world. The empirical data in [Zu20] indicates that at the time of the study approximately 20% of the paths from a DNS/UDP requestor to a DNS/UDP responder blocked packets containing UDP options, i.e., those where the UDP Length was less than the IP Payload Length. This is a sufficiently high failure rate that it is necessary for requestors participating in this experiment to be prepared to fall back to sending requests that do not contain UDP options. This is a signification complication for deployment, and if the number of large responses that can benefit from the use of UDP fragmentation is relatively small, then the resources that are saved from use of UDP fragmentation compared to fallback to TCP may not outweigh the resources that are consumed owing to timeouts caused by middlebox blocking of requests transmitted with UDP options. 7. Security Considerations The off-path cache poisoning attacks documented in [He12] and ][Hl13] are primarily a vulnerability of IPv4 fragmentation owing to its 16-bit Identification field and especially the propensity of IPv4 implementations to generate predictable Identification values. Heard Expires October 28, 2024 [Page 5] Internet-Draft UDP Options for Large DNS Responses April 2024 UDP fragments have 32-bit Identification values [To24] and are intended to be generated in a manner similar to that of IPv6 Fragment ID values [RFC8200]. Algorithms meeting that requirement can be found in [RFC7739]. Implementations of this specification SHOULD use randomized Identification values if the threat of off- path cache poisoning attacks is considered significant. Note that each UDP fragment contains the UDP Source Port, which adds 16 bits of entropy on top of that obtained from the Identification value if the DNS/UDP responder implements source port randomization. 8. IANA Considerations This document requests no IANA actions. 9. References 9.1. Normative References [Fu24] Fujiwara, K., and P. Vixie, "IP Fragmentation Avoidance in DNS over UDP", draft-ietf-dnsop-avoid-fragmentation, February 2024. [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", RFC 6891, April 2013. [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, February 2016. [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, March 2016., RFC 7766, March 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. Heard Expires October 28, 2024 [Page 6] Internet-Draft UDP Options for Large DNS Responses April 2024 [RFC8200] Deering, S., and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 8200, July 2017. [To24] Touch, J., "Transport Options for UDP," draft-ietf-tsvwg- udp-options, March 2024. 9.2. Informative References [He12] Herzberg, A., and H. Shulman, "Fragmentation Considered Poisonous", Arxiv Preprint, May 2012. URL: https://arxiv.org/abs/1205.4011 [Hl13] Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67 Meeting , October 2013. URL: https://ripe67.ripe.net/presentations/240-ipfragattack.pdf [Hu24] Huston, G., "IPv6 Operational Issues (with DNS)", V6OPS Meeting at IETF 119, March 2024. URL: https://datatracker.ietf.org/meeting/119/materials/slides- 119-v6ops-operational-issues-00.pdf [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [Zu20] Zullo, R., Jones, T., and G. Fairhurst, "Overcoming the Sorrows of the Young UDP Options," 2020 Network Traffic Measurement and Analysis Conference (TMA), IEEE, 2020. URL: https://tma.ifip.org/2020/wp- content/uploads/sites/9/2020/06/tma2020-camera-paper70.pdf 10. Acknowledgments This work was inspired by discussions on the IETF TSVWG email list. This document was prepared using 2-Word-v2.0.template.dot. Heard Expires October 28, 2024 [Page 7] Internet-Draft UDP Options for Large DNS Responses April 2024 Author's Address C. M. (Mike) Heard PO Box 2667 Redwood City, CA 94064-2667 USA Phone: +1 (408) 499-7257 Email: heard@pobox.com Heard Expires October 28, 2024 [Page 8]