< draft-ietf-add-dnr-05.txt		draft-ietf-add-dnr-06.txt >
	ADD M. Boucadair, Ed.		ADD M. Boucadair, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy, Ed.		Intended status: Standards Track T. Reddy, Ed.
	Expires: 16 June 2022 Akamai		Expires: 23 September 2022 Akamai
	D. Wing		D. Wing
	Citrix		Citrix
	N. Cook		N. Cook
	Open-Xchange		Open-Xchange
	T. Jensen		T. Jensen
	Microsoft		Microsoft
	13 December 2021		22 March 2022
	DHCP and Router Advertisement Options for the Discovery of Network-		DHCP and Router Advertisement Options for the Discovery of Network-
	designated Resolvers (DNR)		designated Resolvers (DNR)
	draft-ietf-add-dnr-05		draft-ietf-add-dnr-06
	Abstract		Abstract
	The document specifies new DHCP and IPv6 Router Advertisement options		The document specifies new DHCP and IPv6 Router Advertisement options
	to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over-		to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over-
	TLS, DNS-over-QUIC). Particularly, it allows to learn an		TLS, DNS-over-QUIC). Particularly, it allows to learn an
	authentication domain name together with a list of IP addresses and a		authentication domain name together with a list of IP addresses and a
	set of service parameters to reach such encrypted DNS servers.		set of service parameters to reach such encrypted DNS servers.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 16 June 2022.		This Internet-Draft will expire on 23 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	relative DoH URI Template.		relative DoH URI Template.
	A single option is used to convey both the ADN and IP addresses		A single option is used to convey both the ADN and IP addresses
	because otherwise means to correlate an IP address with an ADN will		because otherwise means to correlate an IP address with an ADN will
	be required if, for example, more than one ADN is supported by the		be required if, for example, more than one ADN is supported by the
	network.		network.
	The DHCP options defined in Sections 4 and 5 follow the option		The DHCP options defined in Sections 4 and 5 follow the option
	ordering guidelines in Section 17 of [RFC7227].		ordering guidelines in Section 17 of [RFC7227].
			AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not
			supported because such a mode will trigger additional Do53 queries
			while the data can be supplied directly by DHCP servers. The reader
			may refer to [RFC7969] for an overview of advanced capabilities that
			are supported by DHCP servers to populate configuration data (e.g.,
			issue DNS queries).
	3.2. Handling Configuration Data Conflicts		3.2. Handling Configuration Data Conflicts
	If the encrypted DNS is discovered by a host using both RA and DHCP,		If the encrypted DNS is discovered by a host using both RA and DHCP,
	the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed.		the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed.
	DHCP/RA options to discover encrypted DNS servers (including, DoH URI		DHCP/RA options to discover encrypted DNS servers (including, DoH URI
	Templates) takes precedence over DDR [I-D.ietf-add-ddr] since DDR		Templates) takes precedence over DDR [I-D.ietf-add-ddr] since DDR
	uses unencrypted DNS to an external DNS resolver, which is		uses Do53 to an external DNS resolver, which is susceptible to both
	susceptible to both internal and external attacks whereas DHCP/RA is		internal and external attacks whereas DHCP/RA is typically protected
	typically protected using the mechanisms discussed in Section 7.1.		using the mechanisms discussed in Section 7.1.
	3.3. Connection Establishment		3.3. Connection Establishment
	If the local DNS client supports one of the discovered Encrypted DNS		If the local DNS client supports one of the discovered Encrypted DNS
	protocols identified by Application Layer Protocol Negotiation (ALPN)		protocols identified by Application Layer Protocol Negotiation (ALPN)
	protocol identifiers, the DNS client establishes an encrypted DNS		protocol identifiers, the DNS client establishes an encrypted DNS
	session following the order of the discovered servers. The client		session following the order of the discovered servers. The client
	follows the mechanism discussed in Section 8 of [RFC8310] to		follows the mechanism discussed in Section 8 of [RFC8310] to
	authenticate the DNS server certificate using the authentication		authenticate the DNS server certificate using the authentication
	domain name conveyed in the Encrypted DNS options. ALPN-related		domain name conveyed in the Encrypted DNS options. ALPN-related
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	The fields of the option shown in Figure 1 are as follows:		The fields of the option shown in Figure 1 are as follows:
	Option-code: OPTION_V6_DNR (TBA1, see Section 8.1)		Option-code: OPTION_V6_DNR (TBA1, see Section 8.1)
	Option-length: Length of the enclosed data in octets.		Option-length: Length of the enclosed data in octets.
	Service Priority: The priority of this OPTION_V6_DNR instance		Service Priority: The priority of this OPTION_V6_DNR instance
	compared to other instances. This field is encoded following the		compared to other instances. This field is encoded following the
	rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].		rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].
			AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not
			supported. As such, this field MUST NOT be set to 0.
	Addr Length: Length of enclosed IPv6 addresses in octets. It MUST		Addr Length: Length of enclosed IPv6 addresses in octets. It MUST
	be a multiple of 16.		be a multiple of 16.
	ipv6-address(es) (variable length): Indicates one or more IPv6		ipv6-address(es) (variable length): Indicates one or more IPv6
	addresses to reach the encrypted DNS server. An address can be		addresses to reach the encrypted DNS server. An address can be
	link-local, ULA, or GUA. The format of this field is shown in		link-local, ULA, or GUA. The format of this field is shown in
	Figure 2.		Figure 2.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	The fields of the option shown in Figure 4 are as follows:		The fields of the option shown in Figure 4 are as follows:
	Code: OPTION_V4_DNR (TBA2, see Section 8.2).		Code: OPTION_V4_DNR (TBA2, see Section 8.2).
	Length: Indicates the length of the enclosed data in octets.		Length: Indicates the length of the enclosed data in octets.
	Service Priority: The priority of this OPTION_V4_DNR instance		Service Priority: The priority of this OPTION_V4_DNR instance
	compared to other instances. This field is encoded following the		compared to other instances. This field is encoded following the
	rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].		rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].
			It MUST NOT be set to 0.
	Addr Length: Indicates the length of included IPv4 addresses in		Addr Length: Indicates the length of included IPv4 addresses in
	octets. It MUST be a multiple of 4.		octets. It MUST be a multiple of 4.
	IPv4 Address(es) (variable length): Indicates one or more IPv4		IPv4 Address(es) (variable length): Indicates one or more IPv4
	addresses to reach the encrypted DNS server. Both private and		addresses to reach the encrypted DNS server. Both private and
	public IPv4 addresses can be included in this field. The format		public IPv4 addresses can be included in this field. The format
	of this field is shown in Figure 5. This format assumes that an		of this field is shown in Figure 5. This format assumes that an
	IPv4 address is encoded as a1.a2.a3.a4.		IPv4 address is encoded as a1.a2.a3.a4.
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 21 ¶
	provide the attacker's Encrypted DNS server. Note that such an		provide the attacker's Encrypted DNS server. Note that such an
	attacker can launch other attacks as discussed in Section 22 of		attacker can launch other attacks as discussed in Section 22 of
	[RFC8415]. The attacker can get a domain name with a domain-		[RFC8415]. The attacker can get a domain name with a domain-
	validated public certificate from a CA and host an Encrypted DNS		validated public certificate from a CA and host an Encrypted DNS
	server.		server.
	Attacks of spoofed or modified DHCP responses and RA messages by		Attacks of spoofed or modified DHCP responses and RA messages by
	attackers within the local network may be mitigated by making use of		attackers within the local network may be mitigated by making use of
	the following mechanisms:		the following mechanisms:
	* DHCPv6-Shield described in [RFC7610], the CPE discards DHCP		* DHCPv6-Shield described in [RFC7610], the router (e.g., a border
	response messages received from any local endpoint.		router, a CPE) discards DHCP response messages received from any
			local endpoint.
	* RA-Guard described in [RFC7113], the CPE discards RAs messages		* RA-Guard described in [RFC7113], the router discards RAs messages
	received from any local endpoint.		received from any local endpoint.
	* Source Address Validation Improvement (SAVI) solution for DHCP		* Source Address Validation Improvement (SAVI) solution for DHCP
	described in [RFC7513], the CPE filters packets with forged source		described in [RFC7513], the router filters packets with forged
	IP addresses.		source IP addresses.
	The above mechanisms would ensure that the endpoint receives the		The above mechanisms would ensure that the endpoint receives the
	correct configuration information of the encrypted DNS servers		correct configuration information of the encrypted DNS servers
	selected by the DHCP server (or RA sender), but cannot provide any		selected by the DHCP server (or RA sender), but cannot provide any
	information about the DHCP server or the entity hosting the DHCP		information about the DHCP server or the entity hosting the DHCP
	server (or RA sender) .		server (or RA sender) .
	Encrypted DNS sessions with rogue servers that spoof the IP address		Encrypted DNS sessions with rogue servers that spoof the IP address
	of a DNS server will fail because the DNS client will fail to		of a DNS server will fail because the DNS client will fail to
	authenticate that rogue server based upon PKIX authentication		authenticate that rogue server based upon PKIX authentication
	skipping to change at page 16, line 6 ¶		skipping to change at page 16, line 6 ¶
	+------+--------------------------+----------------+		+------+--------------------------+----------------+
	Table 2		Table 2
	9. Acknowledgements		9. Acknowledgements
	Many thanks to Christian Jacquenet and Michael Richardson for the		Many thanks to Christian Jacquenet and Michael Richardson for the
	review.		review.
	Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane		Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane
	Bortzmeyer, Ben Schwartz, and Iain Sharp for the comments.		Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments.
	Thanks to Mark Nottingham for the feedback on HTTP redirection.		Thanks to Mark Nottingham for the feedback on HTTP redirection.
	The use of DHCP to retrieve an authentication domain name was		The use of DHCP to retrieve an authentication domain name was
	discussed in Section 7.3.1 of [RFC8310] and		discussed in Section 7.3.1 of [RFC8310] and
	[I-D.pusateri-dhc-dns-driu].		[I-D.pusateri-dhc-dns-driu].
	Thanks to Bernie Volz for the review of the DHCP part.		Thanks to Bernie Volz for the review of the DHCP part.
	10. Contributing Authors		10. Contributing Authors
	skipping to change at page 18, line 8 ¶		skipping to change at page 18, line 8 ¶
	<https://papers.mathyvanhoef.com/dragonblood.pdf>.		<https://papers.mathyvanhoef.com/dragonblood.pdf>.
	[Evil-Twin]		[Evil-Twin]
	The Unicode Consortium, "Evil twin (wireless networks)",		The Unicode Consortium, "Evil twin (wireless networks)",
	<https://en.wikipedia.org/wiki/		<https://en.wikipedia.org/wiki/
	Evil_twin_(wireless_networks)>.		Evil_twin_(wireless_networks)>.
	[I-D.ietf-add-ddr]		[I-D.ietf-add-ddr]
	Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.		Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
	Jensen, "Discovery of Designated Resolvers", Work in		Jensen, "Discovery of Designated Resolvers", Work in
	Progress, Internet-Draft, draft-ietf-add-ddr-04, 15		Progress, Internet-Draft, draft-ietf-add-ddr-05, 31
	November 2021, <https://www.ietf.org/archive/id/draft-		January 2022, <https://www.ietf.org/archive/id/draft-ietf-
	ietf-add-ddr-04.txt>.		add-ddr-05.txt>.
	[I-D.ietf-add-svcb-dns]		[I-D.ietf-add-svcb-dns]
	Schwartz, B., "Service Binding Mapping for DNS Servers",		Schwartz, B., "Service Binding Mapping for DNS Servers",
	Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-		Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-
	01, 21 October 2021, <https://www.ietf.org/archive/id/		02, 1 February 2022, <https://www.ietf.org/archive/id/
	draft-ietf-add-svcb-dns-01.txt>.		draft-ietf-add-svcb-dns-02.txt>.
	[I-D.ietf-dprive-dnsoquic]		[I-D.ietf-dprive-dnsoquic]
	Huitema, C., Dickinson, S., and A. Mankin, "DNS over		Huitema, C., Dickinson, S., and A. Mankin, "DNS over
	Dedicated QUIC Connections", Work in Progress, Internet-		Dedicated QUIC Connections", Work in Progress, Internet-
	Draft, draft-ietf-dprive-dnsoquic-07, 1 December 2021,		Draft, draft-ietf-dprive-dnsoquic-11, 21 March 2022,
	<https://www.ietf.org/archive/id/draft-ietf-dprive-		<https://www.ietf.org/archive/id/draft-ietf-dprive-
	dnsoquic-07.txt>.		dnsoquic-11.txt>.
	[I-D.pusateri-dhc-dns-driu]		[I-D.pusateri-dhc-dns-driu]
	Pusateri, T. and W. Toorop, "DHCPv6 Options for private		Pusateri, T. and W. Toorop, "DHCPv6 Options for private
	DNS Discovery", Work in Progress, Internet-Draft, draft-		DNS Discovery", Work in Progress, Internet-Draft, draft-
	pusateri-dhc-dns-driu-00, 2 July 2018,		pusateri-dhc-dns-driu-00, 2 July 2018,
	<https://www.ietf.org/archive/id/draft-pusateri-dhc-dns-		<https://www.ietf.org/archive/id/draft-pusateri-dhc-dns-
	driu-00.txt>.		driu-00.txt>.
	[Krack] The Unicode Consortium, "Key Reinstallation Attacks",		[Krack] The Unicode Consortium, "Key Reinstallation Attacks",
	2017, <https://www.krackattacks.com/>.		2017, <https://www.krackattacks.com/>.
	skipping to change at page 19, line 48 ¶		skipping to change at page 19, line 48 ¶
	[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:		[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
	Protecting against Rogue DHCPv6 Servers", BCP 199,		Protecting against Rogue DHCPv6 Servers", BCP 199,
	RFC 7610, DOI 10.17487/RFC7610, August 2015,		RFC 7610, DOI 10.17487/RFC7610, August 2015,
	<https://www.rfc-editor.org/info/rfc7610>.		<https://www.rfc-editor.org/info/rfc7610>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
			[RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP
			Configuration on the Basis of Network Topology", RFC 7969,
			DOI 10.17487/RFC7969, October 2016,
			<https://www.rfc-editor.org/info/rfc7969>.
	[RFC8146] Harkins, D., "Adding Support for Salted Password Databases		[RFC8146] Harkins, D., "Adding Support for Salted Password Databases
	to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,		to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,
	<https://www.rfc-editor.org/info/rfc8146>.		<https://www.rfc-editor.org/info/rfc8146>.
	[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles		[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
	for DNS over TLS and DNS over DTLS", RFC 8310,		for DNS over TLS and DNS over DTLS", RFC 8310,
	DOI 10.17487/RFC8310, March 2018,		DOI 10.17487/RFC8310, March 2018,
	<https://www.rfc-editor.org/info/rfc8310>.		<https://www.rfc-editor.org/info/rfc8310>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
End of changes. 18 change blocks.
	21 lines changed or deleted		37 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/