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]