< draft-ietf-dnsop-avoid-fragmentation-03.txt		draft-ietf-dnsop-avoid-fragmentation-04.txt >
	Network Working Group K. Fujiwara		Network Working Group K. Fujiwara
	Internet-Draft JPRS		Internet-Draft JPRS
	Intended status: Best Current Practice P. Vixie		Intended status: Best Current Practice P. Vixie
	Expires: 27 May 2021 Farsight		Expires: 26 August 2021 Farsight
	23 November 2020		22 February 2021
	Fragmentation Avoidance in DNS		Fragmentation Avoidance in DNS
	draft-ietf-dnsop-avoid-fragmentation-03		draft-ietf-dnsop-avoid-fragmentation-04
	Abstract		Abstract
	EDNS0 enables a DNS server to send large responses using UDP and is		EDNS0 enables a DNS server to send large responses using UDP and is
	widely deployed. Path MTU discovery remains widely undeployed due to		widely deployed. Path MTU discovery remains widely undeployed due to
	security issues, and IP fragmentation has exposed weaknesses in		security issues, and IP fragmentation has exposed weaknesses in
	application protocols. Currently, DNS is known to be the largest		application protocols. Currently, DNS is known to be the largest
	user of IP fragmentation. It is possible to avoid IP fragmentation		user of IP fragmentation. It is possible to avoid IP fragmentation
	in DNS by limiting response size where possible, and signaling the		in DNS by limiting response size where possible, and signaling the
	need to upgrade from UDP to TCP transport where necessary. This		need to upgrade from UDP to TCP transport where necessary. This
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 27 May 2021.		This Internet-Draft will expire on 26 August 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 4		3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 4
	3.1. Recommendations for UDP responders . . . . . . . . . . . 4		3.1. Recommendations for UDP responders . . . . . . . . . . . 4
	3.2. Recommendations for UDP requestors . . . . . . . . . . . 5		3.2. Recommendations for UDP requestors . . . . . . . . . . . 5
	4. Maximum DNS/UDP payload size . . . . . . . . . . . . . . . . 5		3.3. Default Maximum DNS/UDP payload size . . . . . . . . . . 5
	5. Incremental deployment . . . . . . . . . . . . . . . . . . . 6		4. Incremental deployment . . . . . . . . . . . . . . . . . . . 6
	6. Request to zone operators and DNS server operators . . . . . 7		5. Request to zone operators and DNS server operators . . . . . 7
	7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7		6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 7		6.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. How to retrieve path MTU value to a destination from		Appendix A. How to retrieve path MTU value to a destination from
	applications . . . . . . . . . . . . . . . . . . . . . . 10		applications . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix B. Minimal-responses . . . . . . . . . . . . . . . . . 10		Appendix B. Minimal-responses . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send		DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send
	large responses using UDP. EDNS0 is now widely deployed, and DNS		large responses using UDP. EDNS0 is now widely deployed, and DNS
	(over UDP) is said to be the biggest user of IP fragmentation.		(over UDP) is said to be the biggest user of IP fragmentation.
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	end's MSS parameter and the interface or path MTU, so that the		end's MSS parameter and the interface or path MTU, so that the
	segment size can be chosen so as to keep the each IP datagram below a		segment size can be chosen so as to keep the each IP datagram below a
	target size. This takes advantage of the elasticity of TCP's		target size. This takes advantage of the elasticity of TCP's
	packetizing process as to how much queued data will fit into the next		packetizing process as to how much queued data will fit into the next
	segment. In contrast, DNS over UDP has little datagram size		segment. In contrast, DNS over UDP has little datagram size
	elasticity and lacks insight into IP header and option size, and so		elasticity and lacks insight into IP header and option size, and so
	must make more conservative estimates about available UDP payload		must make more conservative estimates about available UDP payload
	space.		space.
	This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP		This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP
	responses in order to avoid IP fragmentation, and describes how to		messages in order to avoid IP fragmentation, and describes how to
	avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG.		avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	* UDP responders SHOULD send DNS responses with IP_DONTFRAG /		* UDP responders SHOULD send DNS responses with IP_DONTFRAG /
	IPV6_DONTFRAG [RFC3542] options.		IPV6_DONTFRAG [RFC3542] options.
	* If the UDP responder detects immediate error that the UDP packet		* If the UDP responder detects immediate error that the UDP packet
	cannot be sent beyond the path MTU size (EMSGSIZE), the UDP		cannot be sent beyond the path MTU size (EMSGSIZE), the UDP
	responder MAY recreate response packets fit in path MTU size, or		responder MAY recreate response packets fit in path MTU size, or
	TC bit set.		TC bit set.
	* UDP responders MAY probe to discover the real MTU value per		* UDP responders MAY probe to discover the real MTU value per
	destination. If the path MTU discovery failed or is impossible,		destination.
	use the default path MTU described in Section 4.
	* UDP responders SHOULD compose UDP responses that result in IP		* UDP responders SHOULD compose UDP responses that result in IP
	packets that do not exceed the path MTU to the requestor. Of		packets that do not exceed the path MTU to the requestor. If the
	course, as in the conventional case, a specified value (1220 or		path MTU discovery failed or is impossible, UDP responders SHOULD
	1232) as the DNS packet size limit may be used.		compose UDP responses that result in IP packets that do not exceed
			the default maximum DNS/UDP payload size described in Section 3.3.
	The cause and effect of the TC bit is unchanged from EDNS0		The cause and effect of the TC bit is unchanged from EDNS0
	[RFC6891].		[RFC6891].
	3.2. Recommendations for UDP requestors		3.2. Recommendations for UDP requestors
	* UDP requestors SHOULD send DNS responses with IP_DONTFRAG /		* UDP requestors SHOULD send DNS requests with IP_DONTFRAG /
	IPV6_DONTFRAG [RFC3542] options.		IPV6_DONTFRAG [RFC3542] options.
	* UDP requestors MAY probe to discover the real MTU value per		* UDP requestors MAY probe to discover the real MTU value per
	destination. If the path MTU discovery failed or is impossible,		destination. Then, calculate their maximum DNS/UDP payload size
	use the default path MTU described in Section 4.		as the reported path MTU minus IPv4/IPv6 header size (20 or 40)
			minus UDP header size (8). If the path MTU discovery failed or is
			impossible, use the default maximum DNS/UDP payload size described
			in Section 3.3.
	* UDP reqoestors SHOULD use the requestor's payload size to limit		* UDP requestors SHOULD use the requestor's payload size as the
	the path MTU value minus the IP header length and UDP header		calculated or the default maximum DNS/UDP payload size.
	length. Of course, as in the conventional case, a specified value
	(1220 or 1232) as the requestor's payload size may be used.
	* UDP requestors MAY drop fragmented DNS/UDP responses without IP		* UDP requestors MAY drop fragmented DNS/UDP responses without IP
	reassembly to avoid cache poisoning attacks.		reassembly to avoid cache poisoning attacks.
	* DNS responses may be dropped by IP fragmentation. Upon a timeout,		* DNS responses may be dropped by IP fragmentation. Upon a timeout,
	UDP requestors may retry using TCP or UDP, per local policy.		UDP requestors may retry using TCP or UDP, per local policy.
	4. Maximum DNS/UDP payload size		3.3. Default Maximum DNS/UDP payload size
	Default path MTU value for IPv6 is XXXX. Default path MTU value for		Default maximum DNS/UDP payload size for IPv6 is XXXX. (Choose 1232,
	IPv4 is XXXX.		1400, 1472 or other good values before/at WGLC)
	Discussions under here will be deleted when the discussion is over.		Default maximum DNS/UDP payload size for IPv4 is XXXX. (Choose 1232,
	There are many discussions for default path MTU values.		1400, 1452 or other good values before/at WGLC)
			Operators of DNS servers SHOULD measure their path MTU to well-known
			locations on the Internet, such as [a-m].root-servers.net or [a-
			m].gtld-servers.net at setting up the servers. The smallest value of
			path MTU is the server's path MTU to the Internet. The server's
			maximum DNS/UDP payload size for IPv4 is the reported path MTU minus
			IPv4 header size (20) minus UDP header size (8). The server's
			maximum DNS/UDP payload size for IPv6 is the reported path MTU minus
			IPv6 header size (40) minus UDP header size (8).
			Discussions under here will be moved to appendix as a background of
			default maximum DNS/UDP payload size when the discussion is over.
			There are many discussions for default path MTU size and maximum DNS/
			UDP payload size.
	* The minimum MTU for an IPv6 interface is 1280 octets (see		* The minimum MTU for an IPv6 interface is 1280 octets (see
	Section 5 of [RFC8200]). Then, we can use it as default path MTU		Section 5 of [RFC8200]). Then, we can use it as default path MTU
	value for IPv6.		value for IPv6.
	* Most of the Internet and especially the inner core has an MTU of		* Most of the Internet and especially the inner core has an MTU of
	at least 1500 octets. An operator of a full resolver would be		at least 1500 octets. An operator of a full resolver would be
	well advised to measure their path MTU to several authority name		well advised to measure their path MTU to several authority name
	servers and to a random sample of their expected stub resolver		servers and to a random sample of their expected stub resolver
	client networks, to find the upper boundary on IP/UDP packet size		client networks, to find the upper boundary on IP/UDP packet size
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	at least 1220 octets". Then, the smallest number of the maximum		at least 1220 octets". Then, the smallest number of the maximum
	DNS/UDP payload size is 1220.		DNS/UDP payload size is 1220.
	* In order to avoid IP fragmentation, [DNSFlagDay2020] proposed that		* In order to avoid IP fragmentation, [DNSFlagDay2020] proposed that
	the UDP requestors set the requestor's payload size to 1232, and		the UDP requestors set the requestor's payload size to 1232, and
	the UDP responders compose UDP responses fit in 1232 octets. The		the UDP responders compose UDP responses fit in 1232 octets. The
	size 1232 is based on an MTU of 1280, which is required by the		size 1232 is based on an MTU of 1280, which is required by the
	IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP		IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP
	headers.		headers.
	By the above reasoning, this proposal is either too small or too		* [Huston2021] analyzed the result of [DNSFlagDay2020], reported
	large.		that their measurements suggest that in the interior of the
			Internet between recursive resolvers and authoritative servers the
			prevailing MTU is at 1,500 and there is no measurable signal of
			use of smaller MTUs in this part of the Internet, and proposed
			that their measurements suggest setting the EDNS0 Buffer size to
			IPv4 1472 octets and IPv6 1452 octets.
	5. Incremental deployment		4. Incremental deployment
	The proposed method supports incremental deployment.		The proposed method supports incremental deployment.
	When a full-service resolver implements the proposed method, its stub		When a full-service resolver implements the proposed method, its stub
	resolvers (clients) and the authority server network will no longer		resolvers (clients) and the authority server network will no longer
	observe IP fragmentation or reassembly from that server, and will		observe IP fragmentation or reassembly from that server, and will
	fall back to TCP when necessary.		fall back to TCP when necessary.
	When an authoritative server implements the proposed method, its full		When an authoritative server implements the proposed method, its full
	service resolvers (clients) will no longer observe IP fragmentation		service resolvers (clients) will no longer observe IP fragmentation
	or reassembly from that server, and will fall back to TCP when		or reassembly from that server, and will fall back to TCP when
	necessary.		necessary.
	6. Request to zone operators and DNS server operators		5. Request to zone operators and DNS server operators
	Large DNS responses are the result of zone configuration. Zone		Large DNS responses are the result of zone configuration. Zone
	operators SHOULD seek configurations resulting in small responses.		operators SHOULD seek configurations resulting in small responses.
	For example,		For example,
	* Use smaller number of name servers (13 may be too large)		* Use smaller number of name servers (13 may be too large)
	* Use smaller number of A/AAAA RRs for a domain name		* Use smaller number of A/AAAA RRs for a domain name
	* Use 'minimal-responses' configuration: Some implementations have		* Use 'minimal-responses' configuration: Some implementations have
	'minimal responses' configuration that causes DNS servers to make		'minimal responses' configuration that causes DNS servers to make
	response packets smaller, containing only mandatory and required		response packets smaller, containing only mandatory and required
	data (Appendix B).		data (Appendix B).
	* Use smaller signature / public key size algorithm for DNSSEC.		* Use smaller signature / public key size algorithm for DNSSEC.
	Notably, the signature size of ECDSA or EdDSA is smaller than RSA.		Notably, the signature size of ECDSA or EdDSA is smaller than RSA.
	7. Considerations		6. Considerations
	7.1. Protocol compliance		6.1. Protocol compliance
	In prior research ([Fujiwara2018] and dns-operations mailing list		In prior research ([Fujiwara2018] and dns-operations mailing list
	discussions), there are some authoritative servers that ignore EDNS0		discussions), there are some authoritative servers that ignore EDNS0
	requestor's UDP payload size, and return large UDP responses.		requestor's UDP payload size, and return large UDP responses.
	It is also well known that there are some authoritative servers that		It is also well known that there are some authoritative servers that
	do not support TCP transport.		do not support TCP transport.
	Such non-compliant behavior cannot become implementation or		Such non-compliant behavior cannot become implementation or
	configuration constraints for the rest of the DNS. If failure is the		configuration constraints for the rest of the DNS. If failure is the
	result, then that failure must be localized to the non-compliant		result, then that failure must be localized to the non-compliant
	servers.		servers.
	8. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	9. Security Considerations		8. Security Considerations
			9. Acknowledgments
	10. Acknowledgments
	The author would like to specifically thank Paul Wouters, Mukund		The author would like to specifically thank Paul Wouters, Mukund
	Sivaraman and Tony Finch for extensive review and comments.		Sivaraman Tony Finch and Hugo Salgado for extensive review and
			comments.
	11. References		10. References
	11.1. Normative References		10.1. Normative References
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 24 ¶
	[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.		[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
	Völker, "Packetization Layer Path MTU Discovery for		Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,		Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
	September 2020, <https://www.rfc-editor.org/info/rfc8899>.		September 2020, <https://www.rfc-editor.org/info/rfc8899>.
	[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,		[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
	and F. Gont, "IP Fragmentation Considered Fragile",		and F. Gont, "IP Fragmentation Considered Fragile",
	BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,		BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
	<https://www.rfc-editor.org/info/rfc8900>.		<https://www.rfc-editor.org/info/rfc8900>.
	11.2. Informative References		10.2. Informative References
	[Brandt2018]		[Brandt2018]
	Brandt, M., Dai, T., Klein, A., Shulman, H., and M.		Brandt, M., Dai, T., Klein, A., Shulman, H., and M.
	Waidner, "Domain Validation++ For MitM-Resilient PKI",		Waidner, "Domain Validation++ For MitM-Resilient PKI",
	Proceedings of the 2018 ACM SIGSAC Conference on Computer		Proceedings of the 2018 ACM SIGSAC Conference on Computer
	and Communications Security , 2018.		and Communications Security , 2018.
	[DNSFlagDay2020]		[DNSFlagDay2020]
	"DNS flag day 2020", n.d., <https://dnsflagday.net/2020/>.		"DNS flag day 2020", n.d., <https://dnsflagday.net/2020/>.
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 49 ¶
	[Herzberg2013]		[Herzberg2013]
	Herzberg, A. and H. Shulman, "Fragmentation Considered		Herzberg, A. and H. Shulman, "Fragmentation Considered
	Poisonous", IEEE Conference on Communications and Network		Poisonous", IEEE Conference on Communications and Network
	Security , 2013.		Security , 2013.
	[Hlavacek2013]		[Hlavacek2013]
	Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67		Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67
	Meeting , 2013, <https://ripe67.ripe.net/		Meeting , 2013, <https://ripe67.ripe.net/
	presentations/240-ipfragattack.pdf>.		presentations/240-ipfragattack.pdf>.
			[Huston2021]
			Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
			OARC 34 Workshop , February 2021.
	[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,		[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
	"Advanced Sockets Application Program Interface (API) for		"Advanced Sockets Application Program Interface (API) for
	IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,		IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
	<https://www.rfc-editor.org/info/rfc3542>.		<https://www.rfc-editor.org/info/rfc3542>.
	[RFC7739] Gont, F., "Security Implications of Predictable Fragment		[RFC7739] Gont, F., "Security Implications of Predictable Fragment
	Identification Values", RFC 7739, DOI 10.17487/RFC7739,		Identification Values", RFC 7739, DOI 10.17487/RFC7739,
	February 2016, <https://www.rfc-editor.org/info/rfc7739>.		February 2016, <https://www.rfc-editor.org/info/rfc7739>.
	Appendix A. How to retrieve path MTU value to a destination from		Appendix A. How to retrieve path MTU value to a destination from
End of changes. 26 change blocks.
	48 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/