< draft-ietf-dnsop-avoid-fragmentation-04.txt		draft-ietf-dnsop-avoid-fragmentation-05.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: 26 August 2021 Farsight		Expires: 25 December 2021 Farsight
	22 February 2021		23 June 2021
	Fragmentation Avoidance in DNS		Fragmentation Avoidance in DNS
	draft-ietf-dnsop-avoid-fragmentation-04		draft-ietf-dnsop-avoid-fragmentation-05
	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 26 August 2021.		This Internet-Draft will expire on 25 December 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 4		3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 3
	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 . . . . . . . . . . . 4
	3.3. Default Maximum DNS/UDP payload size . . . . . . . . . . 5		3.3. Default Maximum DNS/UDP payload size . . . . . . . . . . 4
	4. Incremental deployment . . . . . . . . . . . . . . . . . . . 6		4. Incremental deployment . . . . . . . . . . . . . . . . . . . 6
	5. Request to zone operators and DNS server operators . . . . . 7		5. Request to zone operators and DNS server operators . . . . . 6
	6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7		6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 7		6.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 7
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. How to retrieve path MTU value to a destination from		Appendix A. Weaknesses of IP fragmentation . . . . . . . . . . . 9
	applications . . . . . . . . . . . . . . . . . . . . . . 10		Appendix B. Details of maximum DNS/UDP payload size
	Appendix B. Minimal-responses . . . . . . . . . . . . . . . . . 10		discussions . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix C. How to retrieve path MTU value to a destination from
			applications . . . . . . . . . . . . . . . . . . . . . . 11
			Appendix D. How to retrieve minimal MTU value to a
			destination . . . . . . . . . . . . . . . . . . . . . . . 11
			Appendix E. Minimal-responses . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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.
	However, "Fragmentation Considered Poisonous" [Herzberg2013] proposed		Fragmented DNS UDP responses have systemic weaknesses, which expose
	effective off-path DNS cache poisoning attack vectors using IP		the requestor to DNS cache poisoning from off-path attackers. (See
	fragmentation. "IP fragmentation attack on DNS" [Hlavacek2013] and		Appendix A for references and details.)
	"Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed
	that off-path attackers can intervene in path MTU discovery [RFC1191]
	to perform intentionally fragmented responses from authoritative
	servers. [RFC7739] stated the security implications of predictable
	fragment identification values.
	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.
	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.
	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 being only 16 bits
	in size, and both likely being in the first fragment of a packet, if
	fragmentation occurs. By comparison, TCP protocol stack controls
	packet size and avoid 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.
	[RFC8900] summarized that IP fragmentation introduces fragility to		[RFC8900] summarized that IP fragmentation introduces fragility to
	Internet communication. The transport of DNS messages over UDP		Internet communication. The transport of DNS messages over UDP
	should take account of the observations stated in that document.		should take account of the observations stated in that document.
	TCP avoids fragmentation using its Maximum Segment Size (MSS)		TCP avoids fragmentation using its Maximum Segment Size (MSS)
	parameter, but each transmitted segment is header-size aware such		parameter, but each transmitted segment is header-size aware such
	that the size of the IP and TCP headers is known, as well as the far		that the size of the IP and TCP headers is known, as well as the far
	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
	skipping to change at page 4, line 23 ¶		skipping to change at page 3, line 39 ¶
	"Requestor" refers to the side that sends a request. "Responder"		"Requestor" refers to the side that sends a request. "Responder"
	refers to an authoritative, recursive resolver or other DNS component		refers to an authoritative, recursive resolver or other DNS component
	that responds to questions. (Quoted from EDNS0 [RFC6891])		that responds to questions. (Quoted from EDNS0 [RFC6891])
	"Path MTU" is the minimum link MTU of all the links in a path between		"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])		a source node and a destination node. (Quoted from [RFC8201])
	"Path MTU discovery" is defined by [RFC1191], [RFC8201] and		"Path MTU discovery" is defined by [RFC1191], [RFC8201] and
	[RFC8899].		[RFC8899].
			IP_DONTFRAG option is not defined by any RFCs. It is similar to
			IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is
			used on BSD systems to set the Don't Fragment bit [RFC0791] when
			sending IPv4 packets. On Linux systems this is done via
			IP_MTU_DISCOVER and IP_PMTUDISC_DO.
	Many of the specialized terms used in this document are defined in		Many of the specialized terms used in this document are defined in
	DNS Terminology [RFC8499].		DNS Terminology [RFC8499].
	3. Proposal to avoid IP fragmentation in DNS		3. Proposal to avoid IP fragmentation in DNS
	The methods to avoid IP fragmentation in DNS are described below:		The methods to avoid IP fragmentation in DNS are described below:
	3.1. Recommendations for UDP responders		3.1. Recommendations for UDP responders
	* UDP responders SHOULD send DNS responses with IP_DONTFRAG /		* UDP responders SHOULD send DNS responses with IP_DONTFRAG /
	skipping to change at page 5, line 28 ¶		skipping to change at page 4, line 50 ¶
	calculated or the default maximum DNS/UDP payload size.		calculated or the default maximum DNS/UDP payload size.
	* 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.
	3.3. Default Maximum DNS/UDP payload size		3.3. Default Maximum DNS/UDP payload size
	Default maximum DNS/UDP payload size for IPv6 is XXXX. (Choose 1232,		Fragmentation avoidance is achieved with the IP(V6)_DONTFRAG option.
	1400, 1472 or other good values before/at WGLC)		The purpose of packet size limitation is to decrease packet loss due
			to the effects of the IP(V6)_DONTFRAG option.
	Default maximum DNS/UDP payload size for IPv4 is XXXX. (Choose 1232,		Default maximum DNS/UDP payload size depends on the connectivity of
	1400, 1452 or other good values before/at WGLC)		each node, it cannot be determined unconditionally. However, there
			are good proposed values.
	Operators of DNS servers SHOULD measure their path MTU to well-known		Operators MAY select a good number from Table 1. Details of proposed
	locations on the Internet, such as [a-m].root-servers.net or [a-		values are described in Appendix B.
	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.		| Source | IPv4 | IPv6 |
			+========================+=============+===================+
			| Minimal: RFC 4035 MUST | 1220 | 1220 |
			+------------------------+-------------+-------------------+
			| Software developers / | 1232 | 1232 (1280-40-8) |
			| DNSFlagDay2020 propose | | |
			+------------------------+-------------+-------------------+
			| Authors' | 1400 | 1400 (1500 -40 -8 |
			| recommendation | | - some headers) |
			+------------------------+-------------+-------------------+
			| Maximum: Ethernet MTU | 1472 | 1452 (1500-40-8) |
			| 1500 [Huston2021] | (1500-20-8) | |
			+------------------------+-------------+-------------------+
			| Measured | MTU -20-8 | MTU -40-8 |
			+------------------------+-------------+-------------------+
	There are many discussions for default path MTU size and maximum DNS/		Table 1: Default maximum DNS/UDP payload size
	UDP payload size.
	* The minimum MTU for an IPv6 interface is 1280 octets (see		However, operators of DNS servers SHOULD measure their path MTU to
	Section 5 of [RFC8200]). Then, we can use it as default path MTU		the Internet at setting up DNS servers (and when network
	value for IPv6.		configuration changes).
	* Most of the Internet and especially the inner core has an MTU of		How to measure path MTU is described in Appendix D.
	at least 1500 octets. An operator of a full resolver would be
	well advised to measure their path MTU to several authority name
	servers and to a random sample of their expected stub resolver
	client networks, to find the upper boundary on IP/UDP packet size
	in the average case. This limit should not be exceeded by most
	messages received or transmitted by a full resolver, or else
	fallback to TCP will occur too often. An operator of
	authoritative servers would also be well advised to measure their
	path MTU to several full-service resolvers. The Linux tool
	"tracepath" can be used to measure the path MTU to well known
	authority name servers such as [a-m].root-servers.net or [a-
	m].gtld-servers.net. If the reported path MTU is for example no
	smaller than 1460, then the maximum DNS/UDP payload would be 1432
	for IP4 (which is 1460 - IP4 header(20) - UDP header(8)) and 1412
	for IP6 (which is 1460 - IP6 header(40) - UDP header(8)). To
	allow for possible IP options and distant tunnel overhead, a
	useful default for maximum DNS/UDP payload size would be 1400.
	* [RFC4035] defines that "A security-aware name server MUST support		Operators of authoritative servers (that offer global DNS zones) and
	the EDNS0 message size extension, MUST support a message size of		full-service resolvers (that access authoritative servers of the
	at least 1220 octets". Then, the smallest number of the maximum		global DNS) SHOULD measure their path MTU to well-known locations on
	DNS/UDP payload size is 1220.		the Internet, such as [a-m].root-servers.net or [a-m].gtld-
			servers.net.
	* In order to avoid IP fragmentation, [DNSFlagDay2020] proposed that		Operators of full-service resolvers would be well advised to measure
	the UDP requestors set the requestor's payload size to 1232, and		their path MTU to several authority name servers and to a random
	the UDP responders compose UDP responses fit in 1232 octets. The		sample of their expected stub resolver client networks, to find the
	size 1232 is based on an MTU of 1280, which is required by the		upper boundary on IP/UDP packet size in the average case. Or,
	IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP		operators of ISPs know their customers' connectivity and customers'
	headers.		MTU to ISPs' servers. This limit should not be exceeded by most
			messages received or transmitted by a full resolver, or else fallback
			to TCP will occur too often.
	* [Huston2021] analyzed the result of [DNSFlagDay2020], reported		DNS clients (stub resolvers) need to specify an appropriate
	that their measurements suggest that in the interior of the		requestor's payload size when supporting EDNS0. In case of CPEs,
	Internet between recursive resolvers and authoritative servers the		embedded devices, and user devices, network operators can not control
	prevailing MTU is at 1,500 and there is no measurable signal of		them, developers may choose small values such as 1220 and 1232.
	use of smaller MTUs in this part of the Internet, and proposed
	that their measurements suggest setting the EDNS0 Buffer size to		Other DNS servers are out-of-scope of this document. (For example,
	IPv4 1472 octets and IPv6 1452 octets.		Forwarding only resolvers, or private DNS).
	4. 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.
	skipping to change at page 7, line 23 ¶		skipping to change at page 6, line 40 ¶
	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 E).
	* 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.
	6. Considerations		6. Considerations
	6.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
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 18 ¶
	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.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. Security Considerations		8. Security Considerations
	9. Acknowledgments		9. Acknowledgments
	The author would like to specifically thank Paul Wouters, Mukund		The author would like to specifically thank Paul Wouters, Mukund
	Sivaraman Tony Finch and Hugo Salgado for extensive review and		Sivaraman, Tony Finch, Hugo Salgado, Peter van Dijk, Brian Dickson,
	comments.		Puneet Sood and Jim Reid for extensive review and comments.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
			DOI 10.17487/RFC0791, September 1981,
			<https://www.rfc-editor.org/info/rfc791>.
	[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>.
			[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
			"Advanced Sockets Application Program Interface (API) for
			IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
			<https://www.rfc-editor.org/info/rfc3542>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/info/rfc4035>.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
	<https://www.rfc-editor.org/info/rfc5155>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891,		for DNS (EDNS(0))", STD 75, RFC 6891,
	DOI 10.17487/RFC6891, April 2013,		DOI 10.17487/RFC6891, April 2013,
	<https://www.rfc-editor.org/info/rfc6891>.		<https://www.rfc-editor.org/info/rfc6891>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	[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.
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 14 ¶
	[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]		[Huston2021]
	Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",		Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
	OARC 34 Workshop , February 2021.		OARC 34 Workshop , February 2021.
	[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	"Advanced Sockets Application Program Interface (API) for		Communication Layers", STD 3, RFC 1122,
	IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc3542>.		<https://www.rfc-editor.org/info/rfc1122>.
			[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
			Security (DNSSEC) Hashed Authenticated Denial of
			Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
			<https://www.rfc-editor.org/info/rfc5155>.
	[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		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
			Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
			March 2017, <https://www.rfc-editor.org/info/rfc8085>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
			Appendix A. Weaknesses of IP fragmentation
			"Fragmentation Considered Poisonous" [Herzberg2013] proposed
			effective off-path DNS cache poisoning attack vectors using IP
			fragmentation. "IP fragmentation attack on DNS" [Hlavacek2013] and
			"Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed
			that off-path attackers can intervene in path MTU discovery [RFC1191]
			to perform intentionally fragmented responses from authoritative
			servers. [RFC7739] stated the security implications of predictable
			fragment identification values.
			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.
			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.
			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 being only 16 bits
			in size, and both likely being in the first fragment of a packet, if
			fragmentation occurs. By comparison, TCP protocol stack controls
			packet size and avoid 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.
			Appendix B. Details of maximum DNS/UDP payload size discussions
			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
			Section 5 of [RFC8200]). Then, we can use it as default path MTU
			value for IPv6. The corresponding minimum MTU for an IPv4
			interface is 68 (60 + 8) [RFC0791].
			* Most of the Internet and especially the inner core has an MTU of
			at least 1500 octets. Maximum DNS/UDP payload size for IPv6 on
			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, authors' recommendation of default
			maximum DNS/UDP payload size is 1400.
			* [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". Then, the smallest number of the maximum
			DNS/UDP payload size is 1220.
			* In order to avoid IP fragmentation, [DNSFlagDay2020] proposed that
			the UDP requestors set the requestor's payload size to 1232, and
			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
			IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP
			headers.
			* [Huston2021] analyzed the result of [DNSFlagDay2020], reported
			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.
			Appendix C. How to retrieve path MTU value to a destination from
	applications		applications
	Socket options: "IP_MTU (since Linux 2.2) Retrieve the current known		Socket options: "IP_MTU (since Linux 2.2) Retrieve the current known
	path MTU of the current socket. Valid only when the socket has been		path MTU of the current socket. Valid only when the socket has been
	connected. Returns an integer. Only valid as a getsockopt(2)."		connected. Returns an integer. Only valid as a getsockopt(2)."
	(Quoted from Debian GNU Linux manual: ip(7))		(Quoted from Debian GNU Linux manual: ip(7))
	"IPV6_MTU getsockopt(): Retrieve the current known path MTU of the		"IPV6_MTU getsockopt(): Retrieve the current known path MTU of the
	current socket. Only valid when the socket has been connected.		current socket. Only valid when the socket has been connected.
	Returns an integer." (Quoted from Debian GNU Linux manual: ipv6(7))		Returns an integer." (Quoted from Debian GNU Linux manual: ipv6(7))
	Appendix B. Minimal-responses		Section 3.4 of [RFC1122] specifies FIND_MAXSIZES() as one of
			"INTERNET/TRANSPORT LAYER INTERFACEs".
			Appendix D. How to retrieve minimal MTU value to a destination
			The Linux tool "tracepath" can be used to measure the path MTU to a
			destination.
			Or, "ping/ping6" command with "-D" Don't Fragment bit set / Disable
			IPv6 fragmentation options.
			Appendix E. Minimal-responses
	Some implementations have 'minimal responses' configuration that		Some implementations have 'minimal responses' configuration that
	causes a DNS server to make response packets smaller, containing only		causes a DNS server to make response packets smaller, containing only
	mandatory and required data.		mandatory and required data.
	Under the minimal-responses configuration, DNS servers compose		Under the minimal-responses configuration, DNS servers compose
	response messages using only RRSets corresponding to queries. In		response messages using only RRSets corresponding to queries. In
	case of delegation, DNS servers compose response packets with		case of delegation, DNS servers compose response packets with
	delegation NS RRSet in authority section and in-domain (in-zone and		delegation NS RRSet in authority section and in-domain (in-zone and
	below-zone) glue in the additional data section. In case of non-		below-zone) glue in the additional data section. In case of non-
End of changes. 30 change blocks.
	127 lines changed or deleted		197 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/