< draft-ietf-dots-signal-channel-32.txt		draft-ietf-dots-signal-channel-33.txt >
	DOTS T. Reddy, Ed.		DOTS T. Reddy, Ed.
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair, Ed.		Intended status: Standards Track M. Boucadair, Ed.
	Expires: November 10, 2019 Orange		Expires: November 11, 2019 Orange
	P. Patil		P. Patil
	Cisco		Cisco
	A. Mortensen		A. Mortensen
	Arbor Networks, Inc.		Arbor Networks, Inc.
	N. Teague		N. Teague
	Verisign, Inc.		Verisign, Inc.
	May 9, 2019		May 10, 2019
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal		Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Specification		Channel Specification
	draft-ietf-dots-signal-channel-32		draft-ietf-dots-signal-channel-33
	Abstract		Abstract
	This document specifies the DOTS signal channel, a protocol for		This document specifies the DOTS signal channel, a protocol for
	signaling the need for protection against Distributed Denial-of-		signaling the need for protection against Distributed Denial-of-
	Service (DDoS) attacks to a server capable of enabling network		Service (DDoS) attacks to a server capable of enabling network
	traffic mitigation on behalf of the requesting client.		traffic mitigation on behalf of the requesting client.
	A companion document defines the DOTS data channel, a separate		A companion document defines the DOTS data channel, a separate
	reliable communication layer for DOTS management and configuration		reliable communication layer for DOTS management and configuration
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 November 10, 2019.		This Internet-Draft will expire on November 11, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38		4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38
	4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40		4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40
	4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41		4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41
	4.5.1. Discover Configuration Parameters . . . . . . . . . . 43		4.5.1. Discover Configuration Parameters . . . . . . . . . . 43
	4.5.2. Convey DOTS Signal Channel Session Configuration . . 47		4.5.2. Convey DOTS Signal Channel Session Configuration . . 47
	4.5.3. Configuration Freshness and Notifications . . . . . . 52		4.5.3. Configuration Freshness and Notifications . . . . . . 52
	4.5.4. Delete DOTS Signal Channel Session Configuration . . 53		4.5.4. Delete DOTS Signal Channel Session Configuration . . 53
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 54		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 54
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 56		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 56
	5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57		5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 57		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 58
	5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 59		5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 60
	5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 63		5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 64
	6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74		6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74
	7. (D)TLS Protocol Profile and Performance Considerations . . . 76		7. (D)TLS Protocol Profile and Performance Considerations . . . 76
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 77		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 78
	7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 79		7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 80
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 80		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 82		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 82
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 82		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 82
	9.3. Media Type Registration . . . . . . . . . . . . . . . . . 82		9.3. Media Type Registration . . . . . . . . . . . . . . . . . 82
	9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 83		9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 83
	9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 83		9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 83
	9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 84		9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 84
	9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 84		9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 84
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	sending more than one UDP datagram per round-trip time (RTT) to the		sending more than one UDP datagram per round-trip time (RTT) to the
	peer DOTS agent on average.		peer DOTS agent on average.
	Requests marked by the DOTS client as Non-confirmable messages are		Requests marked by the DOTS client as Non-confirmable messages are
	sent at regular intervals until a response is received from the DOTS		sent at regular intervals until a response is received from the DOTS
	server. If the DOTS client cannot maintain an RTT estimate, it MUST		server. If the DOTS client cannot maintain an RTT estimate, it MUST
	NOT send more than one Non-confirmable request every 3 seconds, and		NOT send more than one Non-confirmable request every 3 seconds, and
	SHOULD use an even less aggressive rate whenever possible (case 2 in		SHOULD use an even less aggressive rate whenever possible (case 2 in
	Section 3.1.3 of [RFC8085]).		Section 3.1.3 of [RFC8085]).
	JSON encoding is used to illustrate the various methods defined in		JSON encoding of YANG modelled data [RFC7951] is used to illustrate
	the following sub-sections. Also, the examples use the Labels		the various methods defined in the following sub-sections. Also, the
	defined in Sections 9.6.2, 9.6.3, 9.6.4, and 9.6.5.		examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and
			9.6.5.
	4.4.1. Request Mitigation		4.4.1. Request Mitigation
	When a DOTS client requires mitigation for some reason, the DOTS		When a DOTS client requires mitigation for some reason, the DOTS
	client uses the CoAP PUT method to send a mitigation request to its		client uses the CoAP PUT method to send a mitigation request to its
	DOTS server(s) (Figures 5 and 6).		DOTS server(s) (Figures 5 and 6).
	If a DOTS client is entitled to solicit the DOTS service, the DOTS		If a DOTS client is entitled to solicit the DOTS service, the DOTS
	server enables mitigation on behalf of the DOTS client by		server enables mitigation on behalf of the DOTS client by
	communicating the DOTS client's request to a mitigator (which may be		communicating the DOTS client's request to a mitigator (which may be
	skipping to change at page 18, line 50 ¶		skipping to change at page 18, line 50 ¶
	DOTS client.		DOTS client.
	This is a mandatory attribute.		This is a mandatory attribute.
	trigger-mitigation: If the parameter value is set to 'false', DDoS		trigger-mitigation: If the parameter value is set to 'false', DDoS
	mitigation will not be triggered for the mitigation request unless		mitigation will not be triggered for the mitigation request unless
	the DOTS signal channel session is lost.		the DOTS signal channel session is lost.
	If the DOTS client ceases to respond to heartbeat messages, the		If the DOTS client ceases to respond to heartbeat messages, the
	DOTS server can detect that the DOTS signal channel session is		DOTS server can detect that the DOTS signal channel session is
	lost.		lost. More details are discussed in Section 4.7.
	The default value of the parameter is 'true' (that is, the		The default value of the parameter is 'true' (that is, the
	mitigation starts immediately). If 'trigger-mitigation' is not		mitigation starts immediately). If 'trigger-mitigation' is not
	present in a request, this is equivalent to receiving a request		present in a request, this is equivalent to receiving a request
	with 'trigger-mitigation' set to 'true'.		with 'trigger-mitigation' set to 'true'.
	This is an optional attribute.		This is an optional attribute.
	In deployments where server-domain DOTS gateways are enabled,		In deployments where server-domain DOTS gateways are enabled,
	identity information about the origin source client domain ('cdid')		identity information about the origin source client domain ('cdid')
	skipping to change at page 26, line 6 ¶		skipping to change at page 26, line 6 ¶
	an active mitigation request, but both having distinct 'trigger-		an active mitigation request, but both having distinct 'trigger-
	mitigation' types, the DOTS server SHOULD deactivate (absent explicit		mitigation' types, the DOTS server SHOULD deactivate (absent explicit
	policy/configuration otherwise) the mitigation request with 'trigger-		policy/configuration otherwise) the mitigation request with 'trigger-
	mitigation' set to false. Particularly, if the mitigation request		mitigation' set to false. Particularly, if the mitigation request
	with 'trigger-mitigation' set to false is active, the DOTS server		with 'trigger-mitigation' set to false is active, the DOTS server
	withdraws the mitigation request (i.e., status code is set to '7' as		withdraws the mitigation request (i.e., status code is set to '7' as
	defined in Table 2) and transitions the status of the mitigation		defined in Table 2) and transitions the status of the mitigation
	request to '8'.		request to '8'.
	Upon DOTS signal channel session loss with a peer DOTS client, the		Upon DOTS signal channel session loss with a peer DOTS client, the
	DOTS server MUST withdraw (absent explicit policy/configuration		DOTS server SHOULD withdraw (absent explicit policy/configuration
	otherwise) any active mitigation requests overlapping with mitigation		otherwise) any active mitigation requests overlapping with mitigation
	requests having 'trigger-mitigation' set to false from that DOTS		requests having 'trigger-mitigation' set to false from that DOTS
	client, as the loss of the session implictily activates these		client, as the loss of the session implictily activates these
	preconfigured mitigation requests and they take precedence. Note		preconfigured mitigation requests and they take precedence. Note
	that active-but-terminating period is not observed for mitigations		that active-but-terminating period is not observed for mitigations
	withdrawn at the initiative of the DOTS server.		withdrawn at the initiative of the DOTS server.
	DOTS clients may adopt various strategies for setting the scopes of		DOTS clients may adopt various strategies for setting the scopes of
	immediate and pre-configured mitigation requests to avoid potential		immediate and pre-configured mitigation requests to avoid potential
	conflicts. For example, a DOTS client may tweak pre-configured		conflicts. For example, a DOTS client may tweak pre-configured
	skipping to change at page 56, line 12 ¶		skipping to change at page 56, line 12 ¶
	listed in the local configuration or discovered using dynamic means		listed in the local configuration or discovered using dynamic means
	such as DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It		such as DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It
	is RECOMMENDED that DOTS clients support means to alert		is RECOMMENDED that DOTS clients support means to alert
	administrators about redirect loops.		administrators about redirect loops.
	4.7. Heartbeat Mechanism		4.7. Heartbeat Mechanism
	To provide an indication of signal health and distinguish an 'idle'		To provide an indication of signal health and distinguish an 'idle'
	signal channel from a 'disconnected' or 'defunct' session, the DOTS		signal channel from a 'disconnected' or 'defunct' session, the DOTS
	agent sends a heartbeat over the signal channel to maintain its half		agent sends a heartbeat over the signal channel to maintain its half
	of the channel. The DOTS agent similarly expects a heartbeat from		of the channel (also, aligned with the "consents" recommendation in
	its peer DOTS agent, and may consider a session terminated in the		Section 6 of [RFC8085]). The DOTS agent similarly expects a
	prolonged absence of a peer agent heartbeat. Concretely, while the		heartbeat from its peer DOTS agent, and may consider a session
	communication between the DOTS agents is otherwise quiescent, the		terminated in the prolonged absence of a peer agent heartbeat.
	DOTS client will probe the DOTS server to ensure it has maintained		Concretely, while the communication between the DOTS agents is
	cryptographic state and vice versa. Such probes can also keep		otherwise quiescent, the DOTS client will probe the DOTS server to
	firewalls and/or stateful translators bindings alive. This probing		ensure it has maintained cryptographic state and vice versa. Such
	reduces the frequency of establishing a new handshake when a DOTS		probes can also keep firewalls and/or stateful translators bindings
	signal needs to be conveyed to the DOTS server.		alive. This probing reduces the frequency of establishing a new
			handshake when a DOTS signal needs to be conveyed to the DOTS server.
	DOTS servers MAY trigger their heartbeat requests immediately after		DOTS servers MAY trigger their heartbeat requests immediately after
	receiving heartbeat probes from peer DOTS clients. As a reminder, it		receiving heartbeat probes from peer DOTS clients. As a reminder, it
	is the responsibility of DOTS clients to ensure that on-path		is the responsibility of DOTS clients to ensure that on-path
	translators/firewalls are maintaining a binding so that the same		translators/firewalls are maintaining a binding so that the same
	external IP address and/or port number is retained for the DOTS		external IP address and/or port number is retained for the DOTS
	signal channel session.		signal channel session.
	In case of a massive DDoS attack that saturates the incoming link(s)		In case of a massive DDoS attack that saturates the incoming link(s)
	to the DOTS client, all traffic from the DOTS server to the DOTS		to the DOTS client, all traffic from the DOTS server to the DOTS
	skipping to change at page 57, line 11 ¶		skipping to change at page 57, line 11 ¶
	signal channel session, and in parallel, for example, try to		signal channel session, and in parallel, for example, try to
	resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to		resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
	piggyback the mitigation request in the ClientHello message.		piggyback the mitigation request in the ClientHello message.
	As soon as the link is no longer saturated, if traffic from the		As soon as the link is no longer saturated, if traffic from the
	DOTS server reaches the DOTS client over the current DOTS signal		DOTS server reaches the DOTS client over the current DOTS signal
	channel session, the DOTS client can stop (D)TLS session		channel session, the DOTS client can stop (D)TLS session
	resumption or if (D)TLS session resumption is successful then		resumption or if (D)TLS session resumption is successful then
	disconnect the current DOTS signal channel session.		disconnect the current DOTS signal channel session.
			o If the DOTS server receives traffic from the peer DOTS client
			(e.g., peer DOTS client initiated heartbeats) but maximum
			'missing-hb-allowed' threshold is reached, the DOTS server MUST
			NOT consider the DOTS signal channel session disconnected. The
			DOTS server MUST keep on using the current DOTS signal channel
			session so that the DOTS client can send mitigation requests over
			the current DOTS signal channel session. In this case, the DOTS
			server can identify the DOTS client is under attack and the
			inbound link to the DOTS client (domain) is saturated.
			Furthermore, if the DOTS server does not receive a mitigation
			request from the DOTS client, it implies the DOTS client has not
			detected the attack or, if an attack mitigation is in progress, it
			implies the applied DDoS mitigation actions are not yet effective
			to handle the DDoS attack volume.
	o If the DOTS server does not receive any traffic from the peer DOTS		o If the DOTS server does not receive any traffic from the peer DOTS
	client, then the DOTS server sends heartbeat requests to the DOTS		client, then the DOTS server sends heartbeat requests to the DOTS
	client and after maximum 'missing-hb-allowed' threshold is		client and after maximum 'missing-hb-allowed' threshold is
	reached, the DOTS server concludes the session is disconnected.		reached, the DOTS server concludes the session is disconnected.
			The DOTS server can then trigger pre-configured mitigation
			requests for this DOTS client (if any).
	In DOTS over UDP, heartbeat messages MUST be exchanged between the		In DOTS over UDP, heartbeat messages MUST be exchanged between the
	DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of		DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of
	[RFC7252].		[RFC7252].
	In DOTS over TCP, heartbeat messages MUST be exchanged between the		In DOTS over TCP, heartbeat messages MUST be exchanged between the
	DOTS agents using the Ping and Pong messages specified in Section 5.4		DOTS agents using the Ping and Pong messages specified in Section 5.4
	of [RFC8323]. That is, the DOTS agent sends a Ping message and the		of [RFC8323]. That is, the DOTS agent sends a Ping message and the
	peer DOTS agent would respond by sending a single Pong message.		peer DOTS agent would respond by sending a single Pong message.
	skipping to change at page 98, line 5 ¶		skipping to change at page 98, line 5 ¶
	[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security		[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", RFC 7924,		(TLS) Cached Information Extension", RFC 7924,
	DOI 10.17487/RFC7924, July 2016,		DOI 10.17487/RFC7924, July 2016,
	<https://www.rfc-editor.org/info/rfc7924>.		<https://www.rfc-editor.org/info/rfc7924>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.
	[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	the Constrained Application Protocol (CoAP)", RFC 7959,		the Constrained Application Protocol (CoAP)", RFC 7959,
	DOI 10.17487/RFC7959, August 2016,		DOI 10.17487/RFC7959, August 2016,
	<https://www.rfc-editor.org/info/rfc7959>.		<https://www.rfc-editor.org/info/rfc7959>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.		March 2017, <https://www.rfc-editor.org/info/rfc8085>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	skipping to change at page 102, line 40 ¶		skipping to change at page 102, line 40 ¶
	NETCONF Protocol over Transport Layer Security (TLS) with		NETCONF Protocol over Transport Layer Security (TLS) with
	Mutual X.509 Authentication", RFC 7589,		Mutual X.509 Authentication", RFC 7589,
	DOI 10.17487/RFC7589, June 2015,		DOI 10.17487/RFC7589, June 2015,
	<https://www.rfc-editor.org/info/rfc7589>.		<https://www.rfc-editor.org/info/rfc7589>.
	[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>.
			[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
			RFC 7951, DOI 10.17487/RFC7951, August 2016,
			<https://www.rfc-editor.org/info/rfc7951>.
	[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:		[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
	Better Connectivity Using Concurrency", RFC 8305,		Better Connectivity Using Concurrency", RFC 8305,
	DOI 10.17487/RFC8305, December 2017,		DOI 10.17487/RFC8305, December 2017,
	<https://www.rfc-editor.org/info/rfc8305>.		<https://www.rfc-editor.org/info/rfc8305>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
End of changes. 14 change blocks.
	27 lines changed or deleted		46 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/