< draft-ietf-dots-signal-channel-35.txt		draft-ietf-dots-signal-channel-36.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: January 4, 2020 Orange		Expires: January 24, 2020 Orange
	P. Patil		P. Patil
	Cisco		Cisco
	A. Mortensen		A. Mortensen
	Arbor Networks, Inc.		Arbor Networks, Inc.
	N. Teague		N. Teague
	Iron Mountain Data Centers		Iron Mountain Data Centers
	July 3, 2019		July 23, 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-35		draft-ietf-dots-signal-channel-36
	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 January 4, 2020.		This Internet-Draft will expire on January 24, 2020.
	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 12 ¶		skipping to change at page 3, line 12 ¶
	4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12		4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12
	4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13		4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13
	4.4.2. Retrieve Information Related to a Mitigation . . . . 29		4.4.2. Retrieve Information Related to a Mitigation . . . . 29
	4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34		4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34
	4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37		4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37
	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 . . . . . . 53
	4.5.4. Delete DOTS Signal Channel Session Configuration . . 53		4.5.4. Delete DOTS Signal Channel Session Configuration . . 54
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 54		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 56		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57
	5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57		5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 58
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 58		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 59
	5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 60		5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 61
	5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 64		5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 65
	6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74		6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 75
	7. (D)TLS Protocol Profile and Performance Considerations . . . 76		7. (D)TLS Protocol Profile and Performance Considerations . . . 77
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 77
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 78		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 79
	7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 80		7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 81
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 81		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 83		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 84
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 83		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 84
	9.3. Media Type Registration . . . . . . . . . . . . . . . . . 83		9.3. Media Type Registration . . . . . . . . . . . . . . . . . 84
	9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 84		9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 85
	9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 84		9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 85
	9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 85		9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 86
	9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 85		9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 86
	9.6.1.1. Registration Template . . . . . . . . . . . . . . 85		9.6.1.1. Registration Template . . . . . . . . . . . . . . 86
	9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 86		9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 87
	9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 88		9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 89
	9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 89		9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 90
	9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 91		9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 92
	9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 91		9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 92
	9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 92		9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 93
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 93		10. Security Considerations . . . . . . . . . . . . . . . . . . . 94
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 96		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
	13.1. Normative References . . . . . . . . . . . . . . . . . . 96		13.1. Normative References . . . . . . . . . . . . . . . . . . 97
	13.2. Informative References . . . . . . . . . . . . . . . . . 99		13.2. Informative References . . . . . . . . . . . . . . . . . 100
	Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 104		Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 105
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
	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 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	cuid: Stands for Client Unique Identifier. A globally unique		cuid: Stands for Client Unique Identifier. A globally unique
	identifier that is meant to prevent collisions among DOTS		identifier that is meant to prevent collisions among DOTS
	clients, especially those from the same domain. It MUST be		clients, especially those from the same domain. It MUST be
	generated by DOTS clients.		generated by DOTS clients.
	For the reasons discussed in Appendix A, implementations SHOULD		For the reasons discussed in Appendix A, implementations SHOULD
	set 'cuid' using the following procedure: first, the		set 'cuid' using the following procedure: first, the
	Distinguished Encoding Rules (DER)-encoded Abstract Syntax		Distinguished Encoding Rules (DER)-encoded Abstract Syntax
	Notation One (ASN.1) representation of the Subject Public Key		Notation One (ASN.1) representation of the Subject Public Key
	Info (SPKI) of the DOTS client X.509 certificate [RFC5280], the		Info (SPKI) of the DOTS client X.509 certificate [RFC5280], the
	DOTS client raw public key [RFC7250], or the "Pre-Shared Key		DOTS client raw public key [RFC7250], the "Pre-Shared Key (PSK)
	(PSK) identity" used by the DOTS client in the TLS		identity" used by the DOTS client in the TLS 1.2
	ClientKeyExchange message is input to the SHA-256 [RFC6234]		ClientKeyExchange message, or the "identity" used by the DOTS
	cryptographic hash. Then, the output of the cryptographic hash		client in the "pre_shared_key" TLS 1.3 extension is input to
	algorithm is truncated to 16 bytes; truncation is done by		the SHA-256 [RFC6234] cryptographic hash. Then, the output of
	stripping off the final 16 bytes. The truncated output is		the cryptographic hash algorithm is truncated to 16 bytes;
	base64url encoded (Section 5 of [RFC4648]) with the trailing		truncation is done by stripping off the final 16 bytes. The
	"=" removed from the encoding, and the resulting value used as		truncated output is base64url encoded (Section 5 of [RFC4648])
	the 'cuid'.		with the trailing "=" removed from the encoding, and the
			resulting value used as the 'cuid'.
	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		given DOTS server, i.e., the 'cuid' used by a DOTS client
	SHOULD NOT change over time. Distinct 'cuid' values MAY be		SHOULD NOT change over time. Distinct 'cuid' values MAY be
	used by a single DOTS client per DOTS server.		used by a single DOTS client per DOTS server.
	If a DOTS client has to change its 'cuid' for some reason, it		If a DOTS client has to change its 'cuid' for some reason, it
	MUST NOT do so when mitigations are still active for the old		MUST NOT do so when mitigations are still active for the old
	'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS		'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS
	signal message fragmentation over UDP. Furthermore, if that		signal message fragmentation over UDP. Furthermore, if that
	skipping to change at page 42, line 14 ¶		skipping to change at page 42, line 14 ¶
	b. Missing heartbeats allowed (missing-hb-allowed): This variable		b. Missing heartbeats allowed (missing-hb-allowed): This variable
	indicates the maximum number of consecutive heartbeat messages		indicates the maximum number of consecutive heartbeat messages
	for which a DOTS agent did not receive a response before		for which a DOTS agent did not receive a response before
	concluding that the session is disconnected or defunct.		concluding that the session is disconnected or defunct.
	c. Acceptable signal loss ratio: Maximum retransmissions,		c. Acceptable signal loss ratio: Maximum retransmissions,
	retransmission timeout value, and other message transmission		retransmission timeout value, and other message transmission
	parameters for the DOTS signal channel.		parameters for the DOTS signal channel.
			When the DOTS signal channel is established over a reliable transport
			(e.g., TCP), there is no need for the reliability mechanisms provided
			by CoAP over UDP since the underlying TCP connection provides
			retransmissions and deduplication [RFC8323]. As a reminder, CoAP
			over reliable transports does not support Confirmable or Non-
			confirmable message types. As such, the transmission-related
			parameters (missing-hb-allowed and acceptable signal loss ratio) are
			negotiated only for DOTS over unreliable transports.
	The same or distinct configuration sets may be used during times when		The same or distinct configuration sets may be used during times when
	a mitigation is active ('mitigating-config') and when no mitigation		a mitigation is active ('mitigating-config') and when no mitigation
	is active ('idle-config'). This is particularly useful for DOTS		is active ('idle-config'). This is particularly useful for DOTS
	servers that might want to reduce heartbeat frequency or cease		servers that might want to reduce heartbeat frequency or cease
	heartbeat exchanges when an active DOTS client has not requested		heartbeat exchanges when an active DOTS client has not requested
	mitigation. If distinct configurations are used, DOTS agents MUST		mitigation. If distinct configurations are used, DOTS agents MUST
	follow the appropriate configuration set as a function of the		follow the appropriate configuration set as a function of the
	mitigation activity (e.g., if no mitigation request is active (also		mitigation activity (e.g., if no mitigation request is active (also
	referred to as 'idle' time), 'idle-config'-related values must be		referred to as 'idle' time), 'idle-config'-related values must be
	followed). Additionally, DOTS agents MUST automatically switch to		followed). Additionally, DOTS agents MUST automatically switch to
	the other configuration upon a change in the mitigation activity		the other configuration upon a change in the mitigation activity
	(e.g., if an attack mitigation is launched after an 'idle' time, the		(e.g., if an attack mitigation is launched after an 'idle' time, the
	DOTS agent switches from 'idle-config' to 'mitigating-config'-related		DOTS agent switches from 'idle-config' to 'mitigating-config'-related
	values).		values).
			The specification allows for a flexible retry configuration when an
			unreliable transport is in use. For example, a server may be tweaked
			to return the following configuration to be used when a mitigation is
			active:
			o a 'max-retransmit' set to '1' together with a higher 'missing-hb-
			allowed' value (e.g., 34) and a default 'ack-timeout' set to 2
			seconds. This configuration implies more frequent heartbeats in a
			given time span when a loss is encountered.
			o a lower 'missing-hb-allowed' (e.g., 7) value but delegate the
			retransmission (with exponential back-off) to the underlying CoAP
			library by setting 'max-retransmit' to a high value (e.g., 3).
			When a loss is encountered, this configuration implies less
			frequent heartbeats compared to the previous bullet.
			o a higher 'ack-timeout' value (e.g., 10 seconds), a 'max-
			retransmit' set to '1', and a 'missing-hb-allowed' value set to 7.
			Compared to the previous bullet, this configuration reduces by 50%
			the number of required heartbeats from the first transmission of a
			heartbeat message to the time when the DOTS agent gives up.
			o etc.
	CoAP Requests and responses are indicated for reliable delivery by		CoAP Requests and responses are indicated for reliable delivery by
	marking them as Confirmable messages. DOTS signal channel session		marking them as Confirmable messages. DOTS signal channel session
	configuration requests and responses are marked as Confirmable		configuration requests and responses are marked as Confirmable
	messages. As explained in Section 2.1 of [RFC7252], a Confirmable		messages. As explained in Section 2.1 of [RFC7252], a Confirmable
	message is retransmitted using a default timeout and exponential		message is retransmitted using a default timeout and exponential
	back-off between retransmissions, until the DOTS server sends an		back-off between retransmissions, until the DOTS server sends an
	Acknowledgement message (ACK) with the same Message ID conveyed from		Acknowledgement message (ACK) with the same Message ID conveyed from
	the DOTS client.		the DOTS client.
	Message transmission parameters are defined in Section 4.8 of		Message transmission parameters are defined in Section 4.8 of
	skipping to change at page 57, line 39 ¶		skipping to change at page 58, line 39 ¶
	server can then trigger pre-configured mitigation requests for this		server can then trigger pre-configured mitigation requests for this
	DOTS client (if any).		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. The
			sender of a Ping message has to allow up to 'heartbeat-interval'
			seconds when waiting for a Pong reply. When a failure is detected by
			a DOTS client, it proceeds with the session recovery following the
			same approach as the one used for unreliable transports.
	5. DOTS Signal Channel YANG Modules		5. DOTS Signal Channel YANG Modules
	This document defines a YANG [RFC7950] module for DOTS mitigation		This document defines a YANG [RFC7950] module for DOTS mitigation
	scope, DOTS signal channel session configuration data, and DOTS		scope, DOTS signal channel session configuration data, and DOTS
	redirection signaling.		redirection signaling.
	This YANG module (ietf-dots-signal-channel) defines the DOTS client		This YANG module (ietf-dots-signal-channel) defines the DOTS client
	interaction with the DOTS server as seen by the DOTS client. A DOTS		interaction with the DOTS server as seen by the DOTS client. A DOTS
	server is allowed to update the non-configurable 'ro' entities in the		server is allowed to update the non-configurable 'ro' entities in the
	skipping to change at page 96, line 31 ¶		skipping to change at page 97, line 31 ¶
	Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja		Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
	Kuehlewind, and Alissa Cooper for the review.		Kuehlewind, and Alissa Cooper for the review.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-core-hop-limit]		[I-D.ietf-core-hop-limit]
	Boucadair, M., K, R., and J. Shallow, "Constrained		Boucadair, M., K, R., and J. Shallow, "Constrained
	Application Protocol (CoAP) Hop Limit Option", draft-ietf-		Application Protocol (CoAP) Hop-Limit Option", draft-ietf-
	core-hop-limit-03 (work in progress), February 2019.		core-hop-limit-04 (work in progress), July 2019.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	skipping to change at page 100, line 6 ¶		skipping to change at page 101, line 6 ¶
	<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]		[I-D.boucadair-dots-earlydata]
	Boucadair, M. and R. K, "Using Early Data in DOTS", draft-		Boucadair, M. and R. K, "Using Early Data in DOTS", draft-
	boucadair-dots-earlydata-00 (work in progress), January		boucadair-dots-earlydata-00 (work in progress), January
	2019.		2019.
	[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., Bierman, A., and I.
	Management Interface", draft-ietf-core-comi-05 (work in		Petrov, "CoAP Management Interface", draft-ietf-core-
	progress), May 2019.		comi-07 (work in progress), July 2019.
	[I-D.ietf-core-yang-cbor]		[I-D.ietf-core-yang-cbor]
	Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of		Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
	Data Modeled with YANG", draft-ietf-core-yang-cbor-10		Data Modeled with YANG", draft-ietf-core-yang-cbor-10
	(work in progress), April 2019.		(work in progress), April 2019.
	[I-D.ietf-dots-architecture]		[I-D.ietf-dots-architecture]
	Mortensen, A., K, R., Andreasen, F., Teague, N., and R.		Mortensen, A., K, R., Andreasen, F., Teague, N., and R.
	Compton, "Distributed-Denial-of-Service Open Threat		Compton, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-		Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-14 (work in progress), May 2019.		architecture-14 (work in progress), May 2019.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and R. K, "Distributed Denial-of-Service		Boucadair, M. and R. K, "Distributed Denial-of-Service
	Open Threat Signaling (DOTS) Data Channel Specification",		Open Threat Signaling (DOTS) Data Channel Specification",
	draft-ietf-dots-data-channel-29 (work in progress), May		draft-ietf-dots-data-channel-30 (work in progress), July
	2019.		2019.
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M. and R. K, "Multi-homing Deployment		Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment
	Considerations for Distributed-Denial-of-Service Open		Considerations for Distributed-Denial-of-Service Open
	Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01		Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02
	(work in progress), January 2019.		(work in progress), July 2019.
	[I-D.ietf-dots-server-discovery]		[I-D.ietf-dots-server-discovery]
	Boucadair, M. and R. K, "Distributed-Denial-of-Service		Boucadair, M. and R. K, "Distributed-Denial-of-Service
	Open Threat Signaling (DOTS) Server Discovery", draft-		Open Threat Signaling (DOTS) Server Discovery", draft-
	ietf-dots-server-discovery-04 (work in progress), June		ietf-dots-server-discovery-04 (work in progress), June
	2019.		2019.
	[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
	Open Threat Signaling", draft-ietf-dots-use-cases-17 (work		Open Threat Signaling", draft-ietf-dots-use-cases-18 (work
	in progress), January 2019.		in progress), July 2019.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-31 (work in progress), March		1.3", draft-ietf-tls-dtls13-32 (work in progress), July
	2019.		2019.
	[IANA.CBOR.Tags]		[IANA.CBOR.Tags]
	IANA, "Concise Binary Object Representation (CBOR) Tags",		IANA, "Concise Binary Object Representation (CBOR) Tags",
	<http://www.iana.org/assignments/cbor-tags/		<http://www.iana.org/assignments/cbor-tags/
	cbor-tags.xhtml>.		cbor-tags.xhtml>.
	[IANA.CoAP.Content-Formats]		[IANA.CoAP.Content-Formats]
	IANA, "CoAP Content-Formats",		IANA, "CoAP Content-Formats",
	<http://www.iana.org/assignments/core-parameters/		<http://www.iana.org/assignments/core-parameters/
End of changes. 17 change blocks.
	63 lines changed or deleted		101 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/