< draft-ietf-dots-signal-channel-27.txt		draft-ietf-dots-signal-channel-28.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: July 22, 2019 Orange		Expires: August 2, 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.
	January 18, 2019		January 29, 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-27		draft-ietf-dots-signal-channel-28
	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 July 22, 2019.		This Internet-Draft will expire on August 2, 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 24 ¶		skipping to change at page 3, line 24 ¶
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53
	5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 54		5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 54
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54
	5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 56		5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 56
	5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 60		5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 60
	6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 70		6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 70
	7. (D)TLS Protocol Profile and Performance Considerations . . . 73		7. (D)TLS Protocol Profile and Performance Considerations . . . 73
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 73		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 73
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74
	7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 75		7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 76
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 76		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 78		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 78
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 78		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 78
	9.3. Media Type Registration . . . . . . . . . . . . . . . . . 78		9.3. Media Type Registration . . . . . . . . . . . . . . . . . 79
	9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 79		9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 79
	9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 79		9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 79
	9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 80		9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 80
	9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 80		9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 80
	9.6.1.1. Registration Template . . . . . . . . . . . . . . 80		9.6.1.1. Registration Template . . . . . . . . . . . . . . 80
	9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 81		9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 82
	9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 82		9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 83
	9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 84		9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 85
	9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 86		9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 87
	9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 86		9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 87
	9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 87		9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 88
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 88		10. Security Considerations . . . . . . . . . . . . . . . . . . . 89
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 90		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
	13.1. Normative References . . . . . . . . . . . . . . . . . . 90		13.1. Normative References . . . . . . . . . . . . . . . . . . 91
	13.2. Informative References . . . . . . . . . . . . . . . . . 93		13.2. Informative References . . . . . . . . . . . . . . . . . 94
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98
	1. Introduction		1. Introduction
	A distributed denial-of-service (DDoS) attack is a distributed		A distributed denial-of-service (DDoS) attack is a distributed
	attempt to make machines or network resources unavailable to their		attempt to make machines or network resources unavailable to their
	intended users. In most cases, sufficient scale for an effective		intended users. In most cases, sufficient scale for an effective
	attack can be achieved by compromising enough end-hosts and using		attack can be achieved by compromising enough end-hosts and using
	those infected hosts to perpetrate and amplify the attack. The		those infected hosts to perpetrate and amplify the attack. The
	victim in this attack can be an application server, a host, a router,		victim in this attack can be an application server, a host, a router,
	a firewall, or an entire network.		a firewall, or an entire network.
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 29 ¶
	To overcome these connection setup problems, the DOTS client attempts		To overcome these connection setup problems, the DOTS client attempts
	to connect to its DOTS server(s) using both IPv6 and IPv4, and tries		to connect to its DOTS server(s) using both IPv6 and IPv4, and tries
	both DTLS over UDP and TLS over TCP in a manner similar to the Happy		both DTLS over UDP and TLS over TCP in a manner similar to the Happy
	Eyeballs mechanism [RFC8305]. These connection attempts are		Eyeballs mechanism [RFC8305]. These connection attempts are
	performed by the DOTS client when it initializes, or in general when		performed by the DOTS client when it initializes, or in general when
	it has to select an address family and transport to contact its DOTS		it has to select an address family and transport to contact its DOTS
	server. The results of the Happy Eyeballs procedure are used by the		server. The results of the Happy Eyeballs procedure are used by the
	DOTS client for sending its subsequent messages to the DOTS server.		DOTS client for sending its subsequent messages to the DOTS server.
	Note that the DOTS client after successfully establishing a		Note that the DOTS client after successfully establishing a
	connection must cache information regarding the outcome of each		connection MUST cache information regarding the outcome of each
	connection attempt for a specific time period, and it uses that		connection attempt for a specific time period, and it uses that
	information to avoid thrashing the network with subsequent attempts.		information to avoid thrashing the network with subsequent attempts.
	The order of preference of the DOTS signal channel address family and		The order of preference of the DOTS signal channel address family and
	transport protocol (most preferred first) is: UDP over IPv6, UDP over		transport protocol (most preferred first) is: UDP over IPv6, UDP over
	IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres		IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres
	to the address preference order specified in [RFC6724] and the DOTS		to the address preference order specified in [RFC6724] and the DOTS
	signal channel preference which privileges the use of UDP over TCP		signal channel preference which privileges the use of UDP over TCP
	(to avoid TCP's head of line blocking).		(to avoid TCP's head of line blocking).
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	especially those from the same domain. It MUST be generated by		especially those from the same domain. It MUST be generated by
	DOTS clients.		DOTS clients.
	Implementations SHOULD set 'cuid' to the output of a cryptographic		Implementations SHOULD set 'cuid' to the output of a cryptographic
	hash algorithm whose input is the Distinguished Encoding Rules		hash algorithm whose input is the Distinguished Encoding Rules
	(DER)-encoded Abstract Syntax Notation One (ASN.1) representation		(DER)-encoded Abstract Syntax Notation One (ASN.1) representation
	of the Subject Public Key Info (SPKI) of the DOTS client X.509		of the Subject Public Key Info (SPKI) of the DOTS client X.509
	certificate [RFC5280], the DOTS client raw public key [RFC7250],		certificate [RFC5280], the DOTS client raw public key [RFC7250],
	or the "Pre-Shared Key (PSK) identity" used by the DOTS client in		or the "Pre-Shared Key (PSK) identity" used by the DOTS client in
	the TLS ClientKeyExchange message. In this version of the		the TLS ClientKeyExchange message. In this version of the
	specification, the recommended cryptographic hash algorithm is		specification, the cryptographic hash algorithm used is SHA-256
	SHA-256 [RFC6234]. The output of the cryptographic hash algorithm		[RFC6234]. The output of the cryptographic hash algorithm is
	is truncated to 16 bytes; truncation is done by stripping off the		truncated to 16 bytes; truncation is done by stripping off the
	final 16 bytes. The truncated output is base64url encoded.		final 16 bytes. The truncated output is base64url encoded.
	The 'cuid' is intended to be stable when communicating with a		The 'cuid' is intended to be stable when communicating with a
	given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD		given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD
	NOT change over time. Distinct 'cuid' values MAY be used by a		NOT change over time. Distinct 'cuid' values MAY be used by a
	single DOTS client per DOTS server.		single DOTS client per DOTS server.
	DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer		DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer
	to notify that the 'cuid' is already in-use by another DOTS		to notify that the 'cuid' is already in-use by another DOTS
	client. Upon receipt of that error code, a new 'cuid' MUST be		client. Upon receipt of that error code, a new 'cuid' MUST be
	skipping to change at page 74, line 22 ¶		skipping to change at page 74, line 22 ¶
	[RFC4279] with (EC)DHE key exchange which reduces the size of the		[RFC4279] with (EC)DHE key exchange which reduces the size of the
	ServerHello, and can be used by DOTS agents that cannot obtain		ServerHello, and can be used by DOTS agents that cannot obtain
	certificates.		certificates.
	Implementations compliant with this profile SHOULD implement all of		Implementations compliant with this profile SHOULD implement all of
	the following items to reduce the delay required to deliver a DOTS		the following items to reduce the delay required to deliver a DOTS
	signal channel message:		signal channel message:
	o TLS False Start [RFC7918] which reduces round-trips by allowing		o TLS False Start [RFC7918] which reduces round-trips by allowing
	the TLS client's second flight of messages (ChangeCipherSpec) to		the TLS client's second flight of messages (ChangeCipherSpec) to
	also contain the DOTS signal.		also contain the DOTS signal. TLS False Start is formally defined
			for use with TLS, but the same technique is applicable to DTLS as
			well.
	o Cached Information Extension [RFC7924] which avoids transmitting		o Cached Information Extension [RFC7924] which avoids transmitting
	the server's certificate and certificate chain if the client has		the server's certificate and certificate chain if the client has
	cached that information from a previous TLS handshake.		cached that information from a previous TLS handshake.
	o TCP Fast Open [RFC7413] can reduce the number of round-trips to		Compared to UDP, DOTS signal channel over TCP requires an additional
	convey DOTS signal channel message.		round-trip time (RTT) of latency to establish a TCP connection. DOTS
			implementations are encouraged to implement TCP Fast Open [RFC7413]
			to eliminate that RTT.
	7.2. (D)TLS 1.3 Considerations		7.2. (D)TLS 1.3 Considerations
	TLS 1.3 provides critical latency improvements for connection		TLS 1.3 provides critical latency improvements for connection
	establishment over TLS 1.2. The DTLS 1.3 protocol		establishment over TLS 1.2. The DTLS 1.3 protocol
	[I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides		[I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides
	equivalent security guarantees. (D)TLS 1.3 provides two basic		equivalent security guarantees. (D)TLS 1.3 provides two basic
	handshake modes the DOTS signal channel can take advantage of:		handshake modes the DOTS signal channel can take advantage of:
	o A full handshake mode in which a DOTS client can send a DOTS		o A full handshake mode in which a DOTS client can send a DOTS
	skipping to change at page 75, line 14 ¶		skipping to change at page 75, line 17 ¶
	During a DDoS attack, the DOTS client can use the (D)TLS session		During a DDoS attack, the DOTS client can use the (D)TLS session
	to convey the DOTS mitigation request message and, if there is no		to convey the DOTS mitigation request message and, if there is no
	response from the server after multiple retries, the DOTS client		response from the server after multiple retries, the DOTS client
	can resume the (D)TLS session in 0-RTT mode using PSK.		can resume the (D)TLS session in 0-RTT mode using PSK.
	Section 8 of [RFC8446] discusses some mechanisms to implement to		Section 8 of [RFC8446] discusses some mechanisms to implement to
	limit the impact of replay attacks on 0-RTT data. If the DOTS		limit the impact of replay attacks on 0-RTT data. If the DOTS
	server accepts 0-RTT, it MUST implement one of these mechanisms.		server accepts 0-RTT, it MUST implement one of these mechanisms.
	A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.		A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.
			The DOTS signal channel messages sent as early data by the DOTS
			client are idempotent requests. As a reminder, Message ID
			(Section 3 of [RFC7252]) is changed each time a new CoAP request
			is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized
			in each CoAP request. The DOTS server(s) can use Message ID and
			Token in the DOTS signal channel message to detect replay of early
			data, and accept 0-RTT data at most once. Furthermore, 'mid'
			value is monotonically increased by the DOTS client for each
			mitigation request, attackers replaying mitigation requests with
			lower numeric 'mid' values and overlapping scopes with mitigation
			requests having higher numeric 'mid' values will be rejected
			systematically by the DOTS server.
			Owing to the aforementioned protections, especially those afforded
			by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
			anti-replay mechanisms, all DOTS signal channel requests are safe
			to transmit in TLS 1.3 as early data. Refer to
			[I-D.boucadair-dots-earlydata] for more details.
	A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request		A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
	message exchange is shown in Figure 26.		message exchange is shown in Figure 26.
	DOTS Client DOTS Server		DOTS Client DOTS Server
	ClientHello		ClientHello
	(0-RTT DOTS signal message)		(0-RTT DOTS signal message)
	-------->		-------->
	ServerHello		ServerHello
	skipping to change at page 80, line 29 ¶		skipping to change at page 80, line 44 ¶
	9.6.1.1. Registration Template		9.6.1.1. Registration Template
	Parameter name:		Parameter name:
	Parameter name as used in the DOTS signal channel.		Parameter name as used in the DOTS signal channel.
	CBOR Key Value:		CBOR Key Value:
	Key value for the parameter. The key value MUST be an integer in		Key value for the parameter. The key value MUST be an integer in
	the 1-65535 range. The key values of the comprehension-required		the 1-65535 range. The key values of the comprehension-required
	range (0x0001 - 0x3FFF) and of the comprehension-optional range		range (0x0001 - 0x3FFF) and of the comprehension-optional range
	(0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key		(0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of
	values of the comprehension-optional range (0x4000 - 0x7FFF) are		[RFC8126]). The key values of the comprehension-optional range
	assigned by Designated Expert [RFC8126] and of the comprehension-		(0x4000 - 0x7FFF) are assigned by Specification Required
	optional range (0xC000 - 0xFFFF) are reserved for Private Use		(Section 4.6 of [RFC8126]) and of the comprehension-optional range
	[RFC8126].		(0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of
			[RFC8126]).
			Registration requests for the 0x4000 - 0x7FFF range are evaluated
			after a three-week review period on the dots-signal-reg-
			review@ietf.org mailing list, on the advice of one or more
			Designated Experts. However, to allow for the allocation of
			values prior to publication, the Designated Experts may approve
			registration once they are satisfied that such a specification
			will be published. Registration requests sent to the mailing list
			for review should use an appropriate subject (e.g., "Request to
			register CBOR Key Value: example").
			Within the review period, the Designated Experts will either
			approve or deny the registration request, communicating this
			decision to the review list and IANA. Denials should include an
			explanation and, if applicable, suggestions as to how to make the
			request successful. Registration requests that are undetermined
			for a period longer than 21 days can be brought to the IESG's
			attention (using the iesg@ietf.org mailing list) for resolution.
			Criteria that should be applied by the Designated Experts includes
			determining whether the proposed registration duplicates existing
			functionality, whether it is likely to be of general applicability
			or whether it is useful only for a single use case, and whether
			the registration description is clear. IANA must only accept
			registry updates to the 0x4000 - 0x7FFF range from the Designated
			Experts and should direct all requests for registration to the
			review mailing list. It is suggested that multiple Designated
			Experts be appointed. In cases where a registration decision
			could be perceived as creating a conflict of interest for a
			particular Expert, that Expert should defer to the judgment of the
			other Experts.
	CBOR Major Type:		CBOR Major Type:
	CBOR Major type and optional tag for the parameter.		CBOR Major type and optional tag for the parameter.
	Change Controller:		Change Controller:
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party. Other details (e.g., email		name of the responsible party. Other details (e.g., email
	address) may also be included.		address) may also be included.
	Specification Document(s):		Specification Document(s):
	skipping to change at page 92, line 31 ¶		skipping to change at page 93, line 31 ¶
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	[RFC7641] Hartke, K., "Observing Resources in the Constrained		[RFC7641] Hartke, K., "Observing Resources in the Constrained
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/info/rfc7641>.		<https://www.rfc-editor.org/info/rfc7641>.
			[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
			Layer Security (TLS) False Start", RFC 7918,
			DOI 10.17487/RFC7918, August 2016,
			<https://www.rfc-editor.org/info/rfc7918>.
			[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
			(TLS) Cached Information Extension", RFC 7924,
			DOI 10.17487/RFC7924, July 2016,
			<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",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.		<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,
	skipping to change at page 93, line 21 ¶		skipping to change at page 94, line 30 ¶
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/info/rfc8323>.		<https://www.rfc-editor.org/info/rfc8323>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	13.2. Informative References		13.2. Informative References
			[I-D.boucadair-dots-earlydata]
			Boucadair, M. and R. K, "Using Early Data in DOTS", draft-
			boucadair-dots-earlydata-00 (work in progress), January
			2019.
	[I-D.boucadair-dots-server-discovery]		[I-D.boucadair-dots-server-discovery]
	Boucadair, M., K, R., and P. Patil, "Distributed-Denial-		Boucadair, M., K, R., and P. Patil, "Distributed-Denial-
	of-Service Open Threat Signaling (DOTS) Server Discovery",		of-Service Open Threat Signaling (DOTS) Server Discovery",
	draft-boucadair-dots-server-discovery-05 (work in		draft-boucadair-dots-server-discovery-05 (work in
	progress), October 2018.		progress), October 2018.
	[I-D.ietf-core-comi]		[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP		Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
	Management Interface", draft-ietf-core-comi-04 (work in		Management Interface", draft-ietf-core-comi-04 (work in
	progress), November 2018.		progress), November 2018.
	skipping to change at page 94, line 9 ¶		skipping to change at page 95, line 22 ¶
	Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,		Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
	R., and c. christopher_gray3@cable.comcast.com,		R., and c. christopher_gray3@cable.comcast.com,
	"Distributed-Denial-of-Service Open Threat Signaling		"Distributed-Denial-of-Service Open Threat Signaling
	(DOTS) Architecture", draft-ietf-dots-architecture-10		(DOTS) Architecture", draft-ietf-dots-architecture-10
	(work in progress), December 2018.		(work in progress), December 2018.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P.,		Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P.,
	Mortensen, A., and N. Teague, "Distributed Denial-of-		Mortensen, A., and N. Teague, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel		Service Open Threat Signaling (DOTS) Data Channel
	Specification", draft-ietf-dots-data-channel-24 (work in		Specification", draft-ietf-dots-data-channel-25 (work in
	progress), December 2018.		progress), January 2019.
	[I-D.ietf-dots-requirements]		[I-D.ietf-dots-requirements]
	Mortensen, A., Moskowitz, R., and R. K, "Distributed		Mortensen, A., Moskowitz, R., and R. K, "Distributed
	Denial of Service (DDoS) Open Threat Signaling		Denial of Service (DDoS) Open Threat Signaling
	Requirements", draft-ietf-dots-requirements-16 (work in		Requirements", draft-ietf-dots-requirements-16 (work in
	progress), October 2018.		progress), October 2018.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,		Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
	skipping to change at page 97, line 16 ¶		skipping to change at page 98, line 30 ¶
	"Architectural Considerations in Smart Object Networking",		"Architectural Considerations in Smart Object Networking",
	RFC 7452, DOI 10.17487/RFC7452, March 2015,		RFC 7452, DOI 10.17487/RFC7452, March 2015,
	<https://www.rfc-editor.org/info/rfc7452>.		<https://www.rfc-editor.org/info/rfc7452>.
	[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the		[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
	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>.
	[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", RFC 7918,
	DOI 10.17487/RFC7918, August 2016,
	<https://www.rfc-editor.org/info/rfc7918>.
	[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", RFC 7924,
	DOI 10.17487/RFC7924, July 2016,
	<https://www.rfc-editor.org/info/rfc7924>.
	[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>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
End of changes. 18 change blocks.
	44 lines changed or deleted		103 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/