< draft-ietf-dots-signal-channel-19.txt		draft-ietf-dots-signal-channel-20.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: October 11, 2018 Orange		Expires: November 29, 2018 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.
	April 9, 2018		May 28, 2018
	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-19		draft-ietf-dots-signal-channel-20
	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 20 ¶		skipping to change at page 2, line 20 ¶
	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 October 11, 2018.		This Internet-Draft will expire on November 29, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6		3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
	4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8		4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8
	4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8		4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8
	4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9		4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9
	4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10		4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10
	4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11		4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11
	4.4.2. Retrieve Information Related to a Mitigation . . . . 25		4.4.2. Retrieve Information Related to a Mitigation . . . . 25
	4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 33		4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 33
	4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 35		4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 35
	4.5. DOTS Signal Channel Session Configuration . . . . . . . . 36		4.5. DOTS Signal Channel Session Configuration . . . . . . . . 36
	4.5.1. Discover Configuration Parameters . . . . . . . . . . 38		4.5.1. Discover Configuration Parameters . . . . . . . . . . 38
	4.5.2. Convey DOTS Signal Channel Session Configuration . . 42		4.5.2. Convey DOTS Signal Channel Session Configuration . . 42
	4.5.3. Configuration Freshness and Notifications . . . . . . 47		4.5.3. Configuration Freshness and Notifications . . . . . . 47
	4.5.4. Delete DOTS Signal Channel Session Configuration . . 48		4.5.4. Delete DOTS Signal Channel Session Configuration . . 48
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 49		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 49
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 51		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 51
	5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 52		5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 52
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 52		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 52
	5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 54		5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 54
	6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 68		6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 68
	7. (D)TLS Protocol Profile and Performance Considerations . . . 70		7. (D)TLS Protocol Profile and Performance Considerations . . . 70
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 70		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 70
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 71		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 71
	7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73		7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 72
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 75		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 75
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 75		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 75
	9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 75		9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 75
	9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 76		9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 76
	9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76		9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76
	9.5.1. Registration Template . . . . . . . . . . . . . . . . 76		9.5.1. Registration Template . . . . . . . . . . . . . . . . 76
	9.5.2. Initial Registry Content . . . . . . . . . . . . . . 77		9.5.2. Initial Registry Content . . . . . . . . . . . . . . 77
	skipping to change at page 6, line 51 ¶		skipping to change at page 6, line 51 ¶
	has a mutual agreement with its DOTS clients to use a different port		has a mutual agreement with its DOTS clients to use a different port
	number. DOTS clients may alternatively support means to dynamically		number. DOTS clients may alternatively support means to dynamically
	discover the ports used by their DOTS servers. In order to use a		discover the ports used by their DOTS servers. In order to use a
	distinct port number (as opposed to TBD), DOTS clients and servers		distinct port number (as opposed to TBD), DOTS clients and servers
	should support a configurable parameter to supply the port number to		should support a configurable parameter to supply the port number to
	use. The rationale for not using the default port number 5684		use. The rationale for not using the default port number 5684
	((D)TLS CoAP) is to allow for differentiated behaviors in		((D)TLS CoAP) is to allow for differentiated behaviors in
	environments where both a DOTS gateway and an IoT gateway (e.g.,		environments where both a DOTS gateway and an IoT gateway (e.g.,
	Figure 3 of [RFC7452]) are present.		Figure 3 of [RFC7452]) are present.
			The signal channel uses the "coaps" URI scheme defined in Section 6
			of [RFC7252] and "coaps+tcp" URI scheme defined in Section 8.2 of
			[RFC8323] to identify DOTS server resources accessible using CoAP
			over UDP secured with DTLS and CoAP over TCP secured with TLS.
	The signal channel is initiated by the DOTS client (Section 4.4).		The signal channel is initiated by the DOTS client (Section 4.4).
	Once the signal channel is established, the DOTS agents periodically		Once the signal channel is established, the DOTS agents periodically
	send heartbeats to keep the channel active (Section 4.7). At any		send heartbeats to keep the channel active (Section 4.7). At any
	time, the DOTS client may send a mitigation request message to a DOTS		time, the DOTS client may send a mitigation request message to a DOTS
	server over the active channel. While mitigation is active because		server over the active channel. While mitigation is active because
	of the higher likelihood of packet loss during a DDoS attack, the		of the higher likelihood of packet loss during a DDoS attack, the
	DOTS server periodically sends status messages to the client,		DOTS server periodically sends status messages to the client,
	including basic mitigation feedback details. Mitigation remains		including basic mitigation feedback details. Mitigation remains
	active until the DOTS client explicitly terminates mitigation, or the		active until the DOTS client explicitly terminates mitigation, or the
	mitigation lifetime expires.		mitigation lifetime expires.
	skipping to change at page 24, line 8 ¶		skipping to change at page 24, line 8 ¶
	mitigation request by sending back a 2.01 (Created) response to the		mitigation request by sending back a 2.01 (Created) response to the
	DOTS client; the DOTS server will consequently try to mitigate the		DOTS client; the DOTS server will consequently try to mitigate the
	attack.		attack.
	If the DOTS server finds the 'mid' parameter value conveyed in the		If the DOTS server finds the 'mid' parameter value conveyed in the
	PUT request in its configuration data bound to that DOTS client, it		PUT request in its configuration data bound to that DOTS client, it
	MAY update the mitigation request, and a 2.04 (Changed) response is		MAY update the mitigation request, and a 2.04 (Changed) response is
	returned to indicate a successful update of the mitigation request.		returned to indicate a successful update of the mitigation request.
	If the request is conflicting with an existing mitigation request		If the request is conflicting with an existing mitigation request
	from a different DOTS client, and the DOTS server decides to maintain		from a different DOTS client, the DOTS server may return 2.01
	the conflicting mitigation request, the DOTS server returns 4.09		(Created) or 4.09 (Conflict) to the requesting DOTS client. If the
	(Conflict) [RFC8132] to the requesting DOTS client. The response		DOTS server decides to maintain the new mitigation request, the DOTS
			server returns 2.01 (Created) to the requesting DOTS client. If the
			DOTS server decides to reject the new mitigation request, the DOTS
			server returns 4.09 (Conflict) to the requesting DOTS client. For
			both 2.01 (Created) and 4.09 (Conflict) responses, the response
	includes enough information for a DOTS client to recognize the source		includes enough information for a DOTS client to recognize the source
	of the conflict as described below:		of the conflict as described below:
	conflict-information: Indicates that a mitigation request is		conflict-information: Indicates that a mitigation request is
	conflicting with another mitigation request(s) from other DOTS		conflicting with another mitigation request(s) from other DOTS
	client(s). This optional attribute has the following structure:		client(s). This optional attribute has the following structure:
	conflict-status: Indicates the status of a conflicting mitigation		conflict-status: Indicates the status of a conflicting mitigation
	request. The following values are defined:		request. The following values are defined:
	skipping to change at page 30, line 30 ¶		skipping to change at page 30, line 30 ¶
	| 4 | Attack has exceeded the mitigation provider |		| 4 | Attack has exceeded the mitigation provider |
	| | capability. |		| | capability. |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 5 | DOTS client has withdrawn the mitigation request and |		| 5 | DOTS client has withdrawn the mitigation request and |
	| | the mitigation is active but terminating. |		| | the mitigation is active but terminating. |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 6 | Attack mitigation is now terminated. |		| 6 | Attack mitigation is now terminated. |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 7 | Attack mitigation is withdrawn. |		| 7 | Attack mitigation is withdrawn. |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 8 | Attack mitigation is rejected. |
	+-----------+-------------------------------------------------------+
	Table 2: Values of 'status' Parameter		Table 2: Values of 'status' Parameter
	The Observe Option defined in [RFC7641] extends the CoAP core		The Observe Option defined in [RFC7641] extends the CoAP core
	protocol with a mechanism for a CoAP client to "observe" a resource		protocol with a mechanism for a CoAP client to "observe" a resource
	on a CoAP server: The client retrieves a representation of the		on a CoAP server: The client retrieves a representation of the
	resource and requests this representation be updated by the server as		resource and requests this representation be updated by the server as
	long as the client is interested in the resource. A DOTS client		long as the client is interested in the resource. A DOTS client
	conveys the Observe Option set to '0' in the GET request to receive		conveys the Observe Option set to '0' in the GET request to receive
	unsolicited notifications of attack mitigation status from the DOTS		unsolicited notifications of attack mitigation status from the DOTS
	skipping to change at page 31, line 18 ¶		skipping to change at page 31, line 16 ¶
	corresponding policy (e.g., accept all requests, reject all requests,		corresponding policy (e.g., accept all requests, reject all requests,
	accept only one request but reject all the others, ...). It is		accept only one request but reject all the others, ...). It is
	assumed that this policy is supplied by the DOTS server administrator		assumed that this policy is supplied by the DOTS server administrator
	or it is a default behavior of the DOTS server implementation. Then,		or it is a default behavior of the DOTS server implementation. Then,
	the DOTS server sends notification message(s) to the DOTS client(s)		the DOTS server sends notification message(s) to the DOTS client(s)
	at the origin of the conflict (refer to the conflict parameters		at the origin of the conflict (refer to the conflict parameters
	defined in Section 4.4.1). A conflict notification message includes		defined in Section 4.4.1). A conflict notification message includes
	information about the conflict cause, scope, and the status of the		information about the conflict cause, scope, and the status of the
	mitigation request(s). For example,		mitigation request(s). For example,
	o A notification message with 'status' code set to '8 (Attack
	mitigation is rejected)' and 'conflict-status' set to '1' is sent
	to a DOTS client to indicate that this mitigation request is
	rejected because a conflict is detected.
	o A notification message with 'status' code set to '7 (Attack		o A notification message with 'status' code set to '7 (Attack
	mitigation is withdrawn)' and 'conflict-status' set to '1' is sent		mitigation is withdrawn)' and 'conflict-status' set to '1' is sent
	to a DOTS client to indicate that an active mitigation request is		to a DOTS client to indicate that an active mitigation request is
	deactivated because a conflict is detected.		deactivated because a conflict is detected.
	o A notification message with 'status' code set to '1 (Attack		o A notification message with 'status' code set to '1 (Attack
	mitigation is in progress)' and 'conflict-status' set to '2' is		mitigation is in progress)' and 'conflict-status' set to '2' is
	sent to a DOTS client to indicate that this mitigation request is		sent to a DOTS client to indicate that this mitigation request is
	in progress, but a conflict is detected.		in progress, but a conflict is detected.
	skipping to change at page 54, line 44 ¶		skipping to change at page 54, line 44 ¶
	| | | +--ro min-value-decimal? decimal64		| | | +--ro min-value-decimal? decimal64
	| | | +--rw current-value-decimal? decimal64		| | | +--rw current-value-decimal? decimal64
	| | +--rw ack-random-factor		| | +--rw ack-random-factor
	| | +--ro max-value-decimal? decimal64		| | +--ro max-value-decimal? decimal64
	| | +--ro min-value-decimal? decimal64		| | +--ro min-value-decimal? decimal64
	| | +--rw current-value-decimal? decimal64		| | +--rw current-value-decimal? decimal64
	| +--rw trigger-mitigation? boolean		| +--rw trigger-mitigation? boolean
	+--:(redirected-signal)		+--:(redirected-signal)
	+--ro alt-server string		+--ro alt-server string
	+--ro alt-server-record* inet:ip-address		+--ro alt-server-record* inet:ip-address
	+--ro alt-server-ttl? uint32		+--ro alt-server-ttl? int32
	5.2. YANG Module		5.2. YANG Module
	<CODE BEGINS> file "ietf-dots-signal-channel@2018-04-09.yang"		<CODE BEGINS> file "ietf-dots-signal-channel@2018-05-29.yang"
	module ietf-dots-signal-channel {		module ietf-dots-signal-channel {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
	prefix signal;		prefix signal;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	skipping to change at page 56, line 6 ¶		skipping to change at page 56, line 6 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2018-04-09 {		revision 2018-05-29 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification";		Signaling (DOTS) Signal Channel Specification";
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	skipping to change at page 59, line 36 ¶		skipping to change at page 59, line 36 ¶
	enum "attack-mitigation-terminated" {		enum "attack-mitigation-terminated" {
	value 6;		value 6;
	description		description
	"Attack mitigation is now terminated.";		"Attack mitigation is now terminated.";
	}		}
	enum "attack-mitigation-withdrawn" {		enum "attack-mitigation-withdrawn" {
	value 7;		value 7;
	description		description
	"Attack mitigation is withdrawn.";		"Attack mitigation is withdrawn.";
	}		}
	enum "attack-mitigation-rejected" {
	value 8;
	description
	"Attack mitigation is rejected.";
	}
	}		}
	config false;		config false;
	description		description
	"Indicates the status of a mitigation request.		"Indicates the status of a mitigation request.
	It must be included in responses only.";		It must be included in responses only.";
	}		}
	container conflict-information {		container conflict-information {
	config false;		config false;
	description		description
	"Indicates that a conflict is detected.		"Indicates that a conflict is detected.
	skipping to change at page 67, line 20 ¶		skipping to change at page 67, line 15 ¶
	description		description
	"FQDN of an alternate server.";		"FQDN of an alternate server.";
	}		}
	leaf-list alt-server-record {		leaf-list alt-server-record {
	type inet:ip-address;		type inet:ip-address;
	config false;		config false;
	description		description
	"List of records for the alternate server.";		"List of records for the alternate server.";
	}		}
	leaf alt-server-ttl {		leaf alt-server-ttl {
	type uint32;		type int32;
	config false;		config false;
	description		description
	"TTL associated with alt-server records.		"TTL associated with alt-server records.
	A value of negative one (-1) indicates indefinite		A value of negative one (-1) indicates indefinite
	TTL. This value means that the alternate		TTL. This value means that the alternate
	DOTS server is to be used until the alternate DOTS		DOTS server is to be used until the alternate DOTS
	server redirects the traffic with another		server redirects the traffic with another
	3.00 response.";		3.00 response.";
	}		}
	skipping to change at page 70, line 10 ¶		skipping to change at page 70, line 5 ¶
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| idle-config | container | 44 | 5 map | Object |		| idle-config | container | 44 | 5 map | Object |
	| trigger-mitigation | boolean | 45 | 7 bits 20 | False |		| trigger-mitigation | boolean | 45 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| ietf-dots-signal-cha | | | | |		| ietf-dots-signal-cha | | | | |
	|nnel:redirected-signal| container | 46 | 5 map | Object |		|nnel:redirected-signal| container | 46 | 5 map | Object |
	| alt-server | string | 47 | 3 text string | String |		| alt-server | string | 47 | 3 text string | String |
	| alt-server-record | leaf-list | 48 | 4 array | Array |		| alt-server-record | leaf-list | 48 | 4 array | Array |
	| | inet: | | | |		| | inet: | | | |
	| | ip-address | | 3 text string | String |		| | ip-address | | 3 text string | String |
	| alt-server-ttl | uint32 | 49 | 0 unsigned | Number |		| alt-server-ttl | int32 | 49 | 0 unsigned | Number |
	| | | | 1 negative | Number |		| | | | 1 negative | Number |
	+----------------------+-------------+-----+---------------+--------+		+----------------------+-------------+-----+---------------+--------+
	Table 4: CBOR Mappings Used in DOTS Signal Channel Messages		Table 4: CBOR Mappings Used in DOTS Signal Channel Messages
	7. (D)TLS Protocol Profile and Performance Considerations		7. (D)TLS Protocol Profile and Performance Considerations
	7.1. (D)TLS Protocol Profile		7.1. (D)TLS Protocol Profile
	This section defines the (D)TLS protocol profile of DOTS signal		This section defines the (D)TLS protocol profile of DOTS signal
	skipping to change at page 81, line 45 ¶		skipping to change at page 81, line 45 ¶
	[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>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
	FETCH Methods for the Constrained Application Protocol
	(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
	<https://www.rfc-editor.org/info/rfc8132>.
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	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>.
	13.2. Informative References		13.2. Informative References
	[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
	skipping to change at page 82, line 35 ¶		skipping to change at page 82, line 29 ¶
	Mortensen, A., Andreasen, F., Reddy, T.,		Mortensen, A., Andreasen, F., Reddy, T.,
	christopher_gray3@cable.comcast.com, c., Compton, R., and		christopher_gray3@cable.comcast.com, c., Compton, R., and
	N. Teague, "Distributed-Denial-of-Service Open Threat		N. Teague, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-		Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-06 (work in progress), March 2018.		architecture-06 (work in progress), March 2018.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,		Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
	P., Mortensen, A., and N. Teague, "Distributed Denial-of-		P., 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-14 (work in		Specification", draft-ietf-dots-data-channel-16 (work in
	progress), March 2018.		progress), May 2018.
	[I-D.ietf-dots-requirements]		[I-D.ietf-dots-requirements]
	Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed		Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
	Denial of Service (DDoS) Open Threat Signaling		Denial of Service (DDoS) Open Threat Signaling
	Requirements", draft-ietf-dots-requirements-14 (work in		Requirements", draft-ietf-dots-requirements-14 (work in
	progress), February 2018.		progress), February 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
	Open Threat Signaling", draft-ietf-dots-use-cases-11 (work		Open Threat Signaling", draft-ietf-dots-use-cases-12 (work
	in progress), March 2018.		in progress), April 2018.
	[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-26 (work in progress), March		1.3", draft-ietf-tls-dtls13-26 (work in progress), March
	2018.		2018.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
End of changes. 19 change blocks.
	35 lines changed or deleted		28 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/