< draft-ietf-dots-signal-channel-01.txt		draft-ietf-dots-signal-channel-02.txt >
	DOTS T. Reddy		DOTS T. Reddy
	Internet-Draft Cisco		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair		Intended status: Standards Track M. Boucadair
	Expires: October 20, 2017 Orange		Expires: December 23, 2017 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 18, 2017		June 21, 2017
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal		Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel		Channel
	draft-ietf-dots-signal-channel-01		draft-ietf-dots-signal-channel-02
	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. A companion		traffic mitigation on behalf of the requesting client. A companion
	document defines the DOTS data channel, a separate reliable		document defines the DOTS data channel, a separate reliable
	communication layer for DOTS management and configuration.		communication layer for DOTS management and configuration.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 20, 2017.		This Internet-Draft will expire on December 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 28 ¶		skipping to change at page 2, line 28 ¶
	2. Notational Conventions and Terminology . . . . . . . . . . . 3		2. Notational Conventions and Terminology . . . . . . . . . . . 3
	3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4		3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
	4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5		4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5
	5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 7		5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8		5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8
	5.2.1. Mitigation Request Model structure . . . . . . . . . 8		5.2.1. Mitigation Request Model structure . . . . . . . . . 8
	5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8		5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8
	5.2.3. Session Configuration Model structure . . . . . . . . 10		5.2.3. Session Configuration Model structure . . . . . . . . 10
	5.2.4. Session Configuration Model . . . . . . . . . . . . . 10		5.2.4. Session Configuration Model . . . . . . . . . . . . . 10
	5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12		5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 11
	5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12		5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12
	5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17		5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17
	5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18		5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18
	5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23		5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23
	5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25		5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25
	5.4.1. Discover Acceptable Configuration Parameters . . . . 26		5.4.1. Discover Acceptable Configuration Parameters . . . . 26
	5.4.2. Convey DOTS Signal Channel Session Configuration . . 27		5.4.2. Convey DOTS Signal Channel Session Configuration . . 27
	5.4.3. Delete DOTS Signal Channel Session Configuration . . 29		5.4.3. Delete DOTS Signal Channel Session Configuration . . 29
	5.4.4. Retrieving DOTS Signal Channel Session Configuration 29		5.4.4. Retrieving DOTS Signal Channel Session Configuration 29
	5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30		5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	This document satisfies all the use cases discussed in		This document satisfies all the use cases discussed in
	[I-D.ietf-dots-use-cases] except the Third-party DOTS notifications		[I-D.ietf-dots-use-cases] except the Third-party DOTS notifications
	use case in Section 3.2.3 of [I-D.ietf-dots-use-cases] which is an		use case in Section 3.2.3 of [I-D.ietf-dots-use-cases] which is an
	optional feature and not a core use case. Third-party DOTS		optional feature and not a core use case. Third-party DOTS
	notifications are not part of the DOTS requirements document.		notifications are not part of the DOTS requirements document.
	Moreover, the DOTS architecture does not assess whether that use case		Moreover, the DOTS architecture does not assess whether that use case
	may have an impact on the architecture itself and/or the DOTS trust		may have an impact on the architecture itself and/or the DOTS trust
	model.		model.
	This is a companion document to the DOTS data channel specification		This is a companion document to the DOTS data channel specification
	[I-D.reddy-dots-data-channel] that defines a configuration and bulk		[I-D.ietf-dots-data-channel] that defines a configuration and bulk
	data exchange mechanism supporting the DOTS signal channel.		data exchange mechanism supporting the DOTS signal channel.
	2. Notational Conventions and Terminology		2. Notational Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	(D)TLS: For brevity this term is used for statements that apply to		(D)TLS: For brevity this term is used for statements that apply to
	both Transport Layer Security [RFC5246] and Datagram Transport Layer		both Transport Layer Security [RFC5246] and Datagram Transport Layer
	Security [RFC6347]. Specific terms will be used for any statement		Security [RFC6347]. Specific terms will be used for any statement
	that applies to either protocol alone.		that applies to either protocol alone.
	The reader should be familiar with the terms defined in		The reader should be familiar with the terms defined in
	[I-D.ietf-dots-architecture].		[I-D.ietf-dots-architecture].
	3. Solution Overview		3. Solution Overview
	skipping to change at page 4, line 51 ¶		skipping to change at page 4, line 51 ¶
	operating on the access network.		operating on the access network.
	Network		Network
	Resource CPE router Access network __________		Resource CPE router Access network __________
	+-----------+ +--------------+ +-------------+ / \		+-----------+ +--------------+ +-------------+ / \
	| |____| |_______| |___ | Internet |		| |____| |_______| |___ | Internet |
	|DOTS client| | DOTS gateway | | DOTS server | | |		|DOTS client| | DOTS gateway | | DOTS server | | |
	| | | | | | | |		| | | | | | | |
	+-----------+ +--------------+ +-------------+ \__________/		+-----------+ +--------------+ +-------------+ \__________/
	Figure 1		Figure 1: Sample DOTS Deployment (1)
	The DOTS server can also be running on the Internet, as depicted in		The DOTS server can also be running on the Internet, as depicted in
	Figure 2.		Figure 2.
	Network DDoS mitigation		Network DDoS mitigation
	Resource CPE router __________ service		Resource CPE router __________ service
	+-----------+ +-------------+ / \ +-------------+		+-----------+ +-------------+ / \ +-------------+
	| |____| |_______| |___ | |		| |____| |_______| |___ | |
	|DOTS client| |DOTS gateway | | Internet | | DOTS server |		|DOTS client| |DOTS gateway | | Internet | | DOTS server |
	| | | | | | | | |		| | | | | | | | |
	+-----------+ +-------------+ \__________/ +-------------+		+-----------+ +-------------+ \__________/ +-------------+
	Figure 2		Figure 2: Sample DOTS Deployment (2)
	In typical deployments, the DOTS client belongs to a different		In typical deployments, the DOTS client belongs to a different
	administrative domain than the DOTS server. For example, the DOTS		administrative domain than the DOTS server. For example, the DOTS
	client is a firewall protecting services owned and operated by an		client is a firewall protecting services owned and operated by an
	domain, while the DOTS server is owned and operated by a different		domain, while the DOTS server is owned and operated by a different
	domain providing DDoS mitigation services. That domain providing		domain providing DDoS mitigation services. That domain providing
	DDoS mitigation service might, or might not, also provide Internet		DDoS mitigation service might, or might not, also provide Internet
	access service to the website operator.		access service to the website operator.
	The DOTS server may (not) be co-located with the DOTS mitigator. In		The DOTS server may (not) be co-located with the DOTS mitigator. In
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	module: ietf-dots-signal		module: ietf-dots-signal
	+--rw mitigation-scope		+--rw mitigation-scope
	+--rw scope* [mitigation-id]		+--rw scope* [mitigation-id]
	+--rw mitigation-id int32		+--rw mitigation-id int32
	+--rw target-ip* inet:ip-address		+--rw target-ip* inet:ip-address
	+--rw target-prefix* inet:ip-prefix		+--rw target-prefix* inet:ip-prefix
	+--rw target-port-range* [lower-port upper-port]		+--rw target-port-range* [lower-port upper-port]
	| +--rw lower-port inet:port-number		| +--rw lower-port inet:port-number
	| +--rw upper-port inet:port-number		| +--rw upper-port inet:port-number
	+--rw target-protocol* uint8		+--rw target-protocol* uint8
	+--rw FQDN* inet:domain-name		+--rw fqdn* inet:domain-name
	+--rw URI* inet:uri		+--rw uri* inet:uri
	+--rw alias* string		+--rw alias* string
	+--rw lifetime? int32		+--rw lifetime? int32
	5.2.2. Mitigation Request Model		5.2.2. Mitigation Request Model
	<CODE BEGINS> file "ietf-dots-signal@2016-11-28.yang"		<CODE BEGINS> file "ietf-dots-signal@2016-11-28.yang"
	module ietf-dots-signal {		module ietf-dots-signal {
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal";
	prefix "signal";		prefix "signal";
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	}		}
	organization "Cisco Systems, Inc.";		organization "McAfee, Inc.";
	contact "Tirumaleswar Reddy <tireddy@cisco.com>";		contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>";
	description		description
	"This module contains YANG definition for DOTS		"This module contains YANG definition for DOTS
	signal sent by the DOTS client to the DOTS server";		signal sent by the DOTS client to the DOTS server";
	revision 2016-11-28 {		revision 2016-11-28 {
	reference		reference
	"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";		"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
	}		}
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	"The upper-port must be greater than or		"The upper-port must be greater than or
	equal to lower-port";		equal to lower-port";
	}		}
	description "upper port";		description "upper port";
	}		}
	}		}
	leaf-list target-protocol {		leaf-list target-protocol {
	type uint8;		type uint8;
	description "Internet Protocol number";		description "Internet Protocol number";
	}		}
	leaf-list FQDN {		leaf-list fqdn {
	type inet:domain-name;		type inet:domain-name;
	description "FQDN";		description "FQDN";
	}		}
	leaf-list URI {		leaf-list uri {
	type inet:uri;		type inet:uri;
	description "URI";		description "URI";
	}		}
	leaf-list alias {		leaf-list alias {
	type string;		type string;
	description "alias name";		description "alias name";
	}		}
	leaf lifetime {		leaf lifetime {
	type int32;		type int32;
	description "lifetime";		description "lifetime";
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 30 ¶
	module: ietf-dots-signal-config		module: ietf-dots-signal-config
	+--rw signal-config		+--rw signal-config
	+--rw session-id? int32		+--rw session-id? int32
	+--rw heartbeat-timeout? int16		+--rw heartbeat-timeout? int16
	+--rw max-retransmit? int16		+--rw max-retransmit? int16
	+--rw ack-timeout? int16		+--rw ack-timeout? int16
	+--rw ack-random-factor? decimal64		+--rw ack-random-factor? decimal64
	5.2.4. Session Configuration Model		5.2.4. Session Configuration Model
	<CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang"		<CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang"
	module ietf-dots-signal-config {		module ietf-dots-signal-config {
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config";
	prefix "config";		prefix "config";
	organization "Cisco Systems, Inc.";
	contact "Tirumaleswar Reddy <tireddy@cisco.com>";		organization "McAfee, Inc.";
			contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>";
	description		description
	"This module contains YANG definition for DOTS		"This module contains YANG definition for DOTS
	signal channel session configuration";		signal channel session configuration";
	revision 2016-11-28 {		revision 2016-11-28 {
	reference		reference
	"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";		"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
	}		}
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 33 ¶
	type decimal64 {		type decimal64 {
	fraction-digits 2;		fraction-digits 2;
	}		}
	description "Random factor used to influence the timing of		description "Random factor used to influence the timing of
	retransmissions";		retransmissions";
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	5.3. Mitigation Request		5.3. Mitigation Request
	The following methods are used to request or withdraw mitigation		The following methods are used to request or withdraw mitigation
	requests:		requests:
	PUT: DOTS clients use the PUT method to request mitigation		PUT: DOTS clients use the PUT method to request mitigation
	(Section 5.3.1). During active mitigation, DOTS clients may use		(Section 5.3.1). During active mitigation, DOTS clients may use
	PUT requests to convey mitigation efficacy updates to the DOTS		PUT requests to convey mitigation efficacy updates to the DOTS
	server (Section 5.3.4).		server (Section 5.3.4).
	DELETE: DOTS clients use the DELETE method to withdraw a request for		DELETE: DOTS clients use the DELETE method to withdraw a request for
	mitigation from the DOTS server (Section 5.3.2).		mitigation from the DOTS server (Section 5.3.2).
	GET: DOTS clients may use the GET method to subscribe to DOTS server		GET: DOTS clients may use the GET method to subscribe to DOTS server
	status messages, or to retrieve the list of existing mitigations		status messages, or to retrieve the list of existing mitigations
	(Section 5.3.3).		(Section 5.3.3).
	Mitigation request and response messages are marked as Non-		Mitigation request and response messages are marked as Non-
	confirmable messages. DOTS agents should follow the data		confirmable messages. DOTS agents should follow the data
	transmission guidelines discussed in Section 3.1.3 of		transmission guidelines discussed in Section 3.1.3 of [RFC8085] and
	[I-D.ietf-tsvwg-rfc5405bis] and control transmission behavior by not		control transmission behavior by not sending on average more than one
	sending on average more than one UDP datagram per RTT to the peer		UDP datagram per RTT to the peer DOTS agent. Requests marked by the
	DOTS agent. Requests marked by the DOTS client as Non-confirmable		DOTS client as Non-confirmable messages are sent at regular intervals
	messages are sent at regular intervals until a response is received		until a response is received from the DOTS server and if the DOTS
	from the DOTS server and if the DOTS client cannot maintain a RTT		client cannot maintain a RTT estimate then it SHOULD NOT send more
	estimate then it SHOULD NOT send more than one Non-confirmable		than one Non-confirmable request every 3 seconds, and SHOULD use an
	request every 3 seconds, and SHOULD use an even less aggressive rate		even less aggressive rate when possible (case 2 in Section 3.1.3 of
	when possible (case 2 in Section 3.1.3 of		[RFC8085]).
	[I-D.ietf-tsvwg-rfc5405bis]).
	5.3.1. Requesting mitigation		5.3.1. Requesting mitigation
	When a DOTS client requires mitigation for any reason, the DOTS		When a DOTS client requires mitigation for any reason, the DOTS
	client uses CoAP PUT method to send a mitigation request to the DOTS		client uses CoAP PUT method to send a mitigation request to the DOTS
	server (Figure 5, illustrated in JSON diagnostic notation). The DOTS		server (Figure 5, illustrated in JSON diagnostic notation). The DOTS
	server can enable mitigation on behalf of the DOTS client by		server can enable mitigation on behalf of the DOTS client by
	communicating the DOTS client's request to the mitigator and relaying		communicating the DOTS client's request to the mitigator and relaying
	selected mitigator feedback to the requesting DOTS client.		selected mitigator feedback to the requesting DOTS client.
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 31 ¶
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": integer,		"lower-port": integer,
	"upper-port": integer		"upper-port": integer
	}		}
	],		],
	"target-protocol": [		"target-protocol": [
	integer		integer
	],		],
	"FQDN": [		"fqdn": [
	"string"		"string"
	],		],
	"URI": [		"uri": [
	"string"		"string"
	],		],
	"alias": [		"alias": [
	"string"		"string"
	],		],
	"lifetime": integer		"lifetime": integer
	}		}
	]		]
	}		}
	}		}
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	mitigation-id: Identifier for the mitigation request represented		mitigation-id: Identifier for the mitigation request represented
	using an integer. This identifier MUST be unique for each		using an integer. This identifier MUST be unique for each
	mitigation request bound to the DOTS client, i.e., the mitigation-		mitigation request bound to the DOTS client, i.e., the mitigation-
	id parameter value in the mitigation request needs to be unique		id parameter value in the mitigation request needs to be unique
	relative to the mitigation-id parameter values of active		relative to the mitigation-id parameter values of active
	mitigation requests conveyed from the DOTS client to the DOTS		mitigation requests conveyed from the DOTS client to the DOTS
	server. This identifier MUST be generated by the DOTS client.		server. This identifier MUST be generated by the DOTS client.
	This document does not make any assumption about how this		This document does not make any assumption about how this
	identifier is generated. This is a mandatory attribute.		identifier is generated. This is a mandatory attribute.
	target-ip: A list of IP addresses under attack. This is an optional		target-ip: A list of IP addresses under attack. This is an optional
	attribute.		attribute.
	target-prefix: A list of prefixes under attack. Prefixes are		target-prefix: A list of prefixes under attack. Prefixes are
	represented using CIDR notation [RFC4632]. This is an optional		represented using CIDR notation [RFC4632]. This is an optional
	attribute.		attribute.
	target-port-range: A list of ports under attack. The port range,		target-port-range: A list of ports under attack. The port range,
	lower-port for lower port number and upper-port for upper port		lower-port for lower port number and upper-port for upper port
	number. When only lower-port is present, it represents a single		number. When only lower-port is present, it represents a single
	port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g.,		port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g.,
	1024-65535). This is an optional attribute.		1024-65535). This is an optional attribute.
	target-protocol: A list of protocols under attack. Internet		target-protocol: A list of protocols under attack. Internet
	Protocol numbers. This is an optional attribute.		Protocol numbers. This is an optional attribute.
	FQDN: A list of Fully Qualified Domain Names. Fully Qualified
			fqdn: A list of Fully Qualified Domain Names. Fully Qualified
	Domain Name (FQDN) is the full name of a system, rather than just		Domain Name (FQDN) is the full name of a system, rather than just
	its hostname. For example, "venera" is a hostname, and		its hostname. For example, "venera" is a hostname, and
	"venera.isi.edu" is an FQDN. This is an optional attribute.		"venera.isi.edu" is an FQDN. This is an optional attribute.
	URI: A list of Uniform Resource Identifiers (URI). This is an
			uri: A list of Uniform Resource Identifiers (URI). This is an
	optional attribute.		optional attribute.
	alias: A list of aliases. Aliases can be created using the DOTS		alias: A list of aliases. Aliases can be created using the DOTS
	data channel (Section 3.1.1 in [I-D.reddy-dots-data-channel]) or		data channel (Section 3.1.1 in [I-D.ietf-dots-data-channel]) or
	direct connection and then used in subsequent signal channel		direct configuration , or other means and then used in subsequent
	exchanges to refer more efficiently to the resources under attack.		signal channel exchanges to refer more efficiently to the
	This is an optional attribute.		resources under attack. This is an optional attribute.
	lifetime: Lifetime of the mitigation request in seconds. Upon the		lifetime: Lifetime of the mitigation request in seconds. Upon the
	expiry of this lifetime, and if the request is not refreshed, the		expiry of this lifetime, and if the request is not refreshed, the
	mitigation request is removed. The request can be refreshed by		mitigation request is removed. The request can be refreshed by
	sending the same request again. The default lifetime of the		sending the same request again. The default lifetime of the
	mitigation request is 3600 seconds (60 minutes) -- this value was		mitigation request is 3600 seconds (60 minutes) -- this value was
	chosen to be long enough so that refreshing is not typically a		chosen to be long enough so that refreshing is not typically a
	burden on the DOTS client, while expiring the request where the		burden on the DOTS client, while expiring the request where the
	client has unexpectedly quit in a timely manner. A lifetime of		client has unexpectedly quit in a timely manner. A lifetime of
	zero indicates indefinite lifetime for the mitigation request.		zero indicates indefinite lifetime for the mitigation request.
	The server MUST always indicate the actual lifetime in the		The server MUST always indicate the actual lifetime in the
	response and the remaining lifetime in status messages sent to the		response and the remaining lifetime in status messages sent to the
	client. This is an optional attribute in the request.		client. This is an optional attribute in the request.
	The CBOR key values for the parameters are defined in Section 6. The		The CBOR key values for the parameters are defined in Section 6. The
	IANA Considerations section defines how the CBOR key values can be		IANA Considerations section defines how the CBOR key values can be
	allocated to standards bodies and vendors. In the PUT request at		allocated to standards bodies and vendors. In the PUT request at
	least one of the attributes target-ip or target-prefix or FQDN or URI		least one of the attributes target-ip or target-prefix or fqdn or uri
	or alias MUST be present. DOTS agents can safely ignore Vendor-		or alias MUST be present. DOTS agents can safely ignore Vendor-
	Specific parameters they don't understand. The relative order of two		Specific parameters they don't understand. The relative order of two
	mitigation requests from a DOTS client is determined by comparing		mitigation requests from a DOTS client is determined by comparing
	their respective mitigation-id values. If two mitigation requests		their respective mitigation-id values. If two mitigation requests
	have overlapping mitigation scopes the mitigation request with higher		have overlapping mitigation scopes the mitigation request with higher
	numeric mitigation-id value will override the mitigation request with		numeric mitigation-id value will override the mitigation request with
	a lower numeric mitigation-id value. The Uri-Path option carries a		a lower numeric mitigation-id value. The Uri-Path option carries a
	major and minor version nomenclature to manage versioning and DOTS		major and minor version nomenclature to manage versioning and DOTS
	signal channel in this specification uses v1 major version.		signal channel in this specification uses v1 major version.
	In both DOTS signal and data channel sessions, the DOTS client MUST		In both DOTS signal and data channel sessions, the DOTS client MUST
	authenticate itself to the DOTS server (Section 9). The DOTS server		authenticate itself to the DOTS server (Section 9). The DOTS server
	couples the DOTS signal and data channel sessions using the DOTS		can use the algorithm discussed in Section 7 of [RFC7589] to derive
	client identity, so the DOTS server can validate whether the aliases		the DOTS client identity or username from the client certificate.
	conveyed in the mitigation request were indeed created by the same		The DOTS server couples the DOTS signal and data channel sessions
	DOTS client using the DOTS data channel session. If the aliases were		using the DOTS client identity, so the DOTS server can validate
	not created by the DOTS client then the DOTS server returns 4.00 (Bad		whether the aliases conveyed in the mitigation request were indeed
	Request) in the response. The DOTS server couples the DOTS signal		created by the same DOTS client using the DOTS data channel session.
	channel sessions using the DOTS client identity, and the DOTS server		If the aliases were not created by the DOTS client then the DOTS
	uses mitigation-id parameter value to detect duplicate mitigation		server returns 4.00 (Bad Request) in the response. The DOTS server
	requests.		couples the DOTS signal channel sessions using the DOTS client
			identity, and the DOTS server uses mitigation-id parameter value to
			detect duplicate mitigation requests.
	Figure 6 shows a PUT request example to signal that ports 80, 8080,		Figure 6 shows a PUT request example to signal that ports 80, 8080,
	and 443 on the servers 2002:db8:6401::1 and 2002:db8:6401::2 are		and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are
	being attacked (illustrated in JSON diagnostic notation).		being attacked (illustrated in JSON diagnostic notation).
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "www.example.com"		Uri-Host: "www.example.com"
	Uri-Path: "v1"		Uri-Path: "v1"
	Uri-Path: "dots-signal"		Uri-Path: "dots-signal"
	Uri-Path: "signal"		Uri-Path: "signal"
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"mitigation-scope": {		"mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mitigation-id": 12332,		"mitigation-id": 12332,
	"target-ip": [		"target-ip": [
	"2002:db8:6401::1",		"2001:db8:6401::1",
	"2002:db8:6401::2"		"2001:db8:6401::2"
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": 80		"lower-port": 80
	},		},
	{		{
	"lower-port": 443		"lower-port": 443
	},		},
	{		{
	"lower-port": 8080		"lower-port": 8080
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 38 ¶
	01 # unsigned(1)		01 # unsigned(1)
	a1 # map(1)		a1 # map(1)
	02 # unsigned(2)		02 # unsigned(2)
	81 # array(1)		81 # array(1)
	a4 # map(4)		a4 # map(4)
	03 # unsigned(3)		03 # unsigned(3)
	19 302c # unsigned(12332)		19 302c # unsigned(12332)
	04 # unsigned(4)		04 # unsigned(4)
	82 # array(2)		82 # array(2)
	70 # text(16)		70 # text(16)
	323030323a6462383a363430313a3a31 # "2002:db8:6401::1"		323030313A6462383A363430313A3A31 # "2001:db8:6401::1"
	70 # text(16)		70 # text(16)
	323030323a6462383a363430313a3a32 # "2002:db8:6401::2"		323030313A6462383A363430313A3A32 # "2001:db8:6401::2"
	05 # unsigned(5)		05 # unsigned(5)
	83 # array(3)		83 # array(3)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	18 50 # unsigned(80)		18 50 # unsigned(80)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	19 01bb # unsigned(443)		19 01bb # unsigned(443)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	skipping to change at page 16, line 42 ¶		skipping to change at page 17, line 4 ¶
	83 # array(3)		83 # array(3)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	18 50 # unsigned(80)		18 50 # unsigned(80)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	19 01bb # unsigned(443)		19 01bb # unsigned(443)
	a1 # map(1)		a1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	19 1f90 # unsigned(8080)		19 1f90 # unsigned(8080)
	08 # unsigned(8)		08 # unsigned(8)
	81 # array(1)		81 # array(1)
	06 # unsigned(6)		06 # unsigned(6)
	Figure 6: POST for DOTS signal		Figure 6: POST for DOTS signal
	The DOTS server indicates the result of processing the PUT request		The DOTS server indicates the result of processing the PUT request
	using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx		using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx
	codes are some sort of invalid requests. COAP 5.xx codes are		codes are some sort of invalid requests. COAP 5.xx codes are
	returned if the DOTS server has erred or is currently unavailable to		returned if the DOTS server has erred or is currently unavailable to
	provide mitigation in response to the mitigation request from the		provide mitigation in response to the mitigation request from the
	DOTS client. If the DOTS server does not find the mitigation-id		DOTS client. If the DOTS server does not find the mitigation-id
	parameter value conveyed in the PUT request in its configuration data		parameter value conveyed in the PUT request in its configuration data
	then the server MAY accept the mitigation request, and a 2.01		then the server MAY accept the mitigation request, and a 2.01
	(Created) response is returned to the DOTS client, and the DOTS		(Created) response is returned to the DOTS client, and the DOTS
	server will try to mitigate the attack. If the DOTS server finds the		server will try to mitigate the attack. If the DOTS server finds the
	mitigation-id parameter value conveyed in the PUT request in its		mitigation-id parameter value conveyed in the PUT request in its
	configuration data then the server MAY update the mitigation request,		configuration data then the server MAY update the mitigation request,
	and a 2.04 (Changed) response is returned to indicate a successful		and a 2.04 (Changed) response is returned to indicate a successful
	updation of the mitigation request. If the request is missing one or		update of the mitigation request. If the request is missing one or
	more mandatory attributes, then 4.00 (Bad Request) will be returned		more mandatory attributes, then 4.00 (Bad Request) will be returned
	in the response or if the request contains invalid or unknown		in the response or if the request contains invalid or unknown
	parameters then 4.02 (Invalid query) will be returned in the		parameters then 4.02 (Invalid query) will be returned in the
	response. For responses indicating a client or server error, the		response. For responses indicating a client or server error, the
	payload explains the error situation of the result of the requested		payload explains the error situation of the result of the requested
	action (Section 5.5 in [RFC7252]).		action (Section 5.5 in [RFC7252]).
	5.3.2. Withdraw a DOTS Signal		5.3.2. Withdraw a DOTS Signal
	A DELETE request is used to withdraw a DOTS signal from a DOTS server		A DELETE request is used to withdraw a DOTS signal from a DOTS server
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 32 ¶
	If the DOTS server does not find the mitigation-id parameter value		If the DOTS server does not find the mitigation-id parameter value
	conveyed in the DELETE request in its configuration data, then it		conveyed in the DELETE request in its configuration data, then it
	responds with a 4.04 (Not Found) error response code. The DOTS		responds with a 4.04 (Not Found) error response code. The DOTS
	server successfully acknowledges a DOTS client's request to withdraw		server successfully acknowledges a DOTS client's request to withdraw
	the DOTS signal using 2.02 (Deleted) response code, and ceases		the DOTS signal using 2.02 (Deleted) response code, and ceases
	mitigation activity as quickly as possible.		mitigation activity as quickly as possible.
	To protect against route or DNS flapping caused by a client rapidly		To protect against route or DNS flapping caused by a client rapidly
	toggling mitigation, and to dampen the effect of oscillating attacks,		toggling mitigation, and to dampen the effect of oscillating attacks,
	DOTS servers MAY continue mitigation for a period of up to fifteen		DOTS servers MAY continue mitigation for a period of up to five
	minutes after acknowledging a DOTS client's withdrawal of a		minutes after acknowledging a DOTS client's withdrawal of a
	mitigation request. During this period, DOTS server mitigation		mitigation request. During this period, DOTS server status messages
	status messages SHOULD indicate that mitigation is active but		SHOULD indicate that mitigation is active but terminating. After the
	terminating. After the fifteen-minute period elapses, the DOTS		five-minute period elapses, the DOTS server MUST treat the mitigation
	server MUST treat the mitigation as terminated, as the DOTS client is		as terminated, as the DOTS client is no longer responsible for the
	no longer responsible for the mitigation.		mitigation. For example, if there is a financial relationship
			between the DOTS client and server domains, the DOTS client ceases
			incurring cost at this point.
	5.3.3. Retrieving a DOTS Signal		5.3.3. Retrieving a DOTS Signal
	A GET request is used to retrieve information and status of a DOTS		A GET request is used to retrieve information and status of a DOTS
	signal from a DOTS server (Figure 8). If the DOTS server does not		signal from a DOTS server (Figure 8). If the DOTS server does not
	find the mitigation-id parameter value conveyed in the GET request in		find the mitigation-id parameter value conveyed in the GET request in
	its configuration data, then it responds with a 4.04 (Not Found)		its configuration data, then it responds with a 4.04 (Not Found)
	error response code. The 'c' (content) parameter and its permitted		error response code. The 'c' (content) parameter and its permitted
	values defined in [I-D.ietf-core-comi] can be used to retrieve non-		values defined in [I-D.ietf-core-comi] can be used to retrieve non-
	configuration data or configuration data or both.		configuration data or configuration data or both.
	skipping to change at page 24, line 28 ¶		skipping to change at page 24, line 28 ¶
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": integer,		"lower-port": integer,
	"upper-port": integer		"upper-port": integer
	}		}
	],		],
	"target-protocol": [		"target-protocol": [
	integer		integer
	],		],
	"FQDN": [		"fqdn": [
	"string"		"string"
	],		],
	"URI": [		"uri": [
	"string"		"string"
	],		],
	"alias": [		"alias": [
	"string"		"string"
	],		],
	"lifetime": integer,		"lifetime": integer,
	"attack-status": integer		"attack-status": integer
	}		}
	]		]
	}		}
	skipping to change at page 27, line 45 ¶		skipping to change at page 27, line 45 ¶
	Figure 14: POST to convey the DOTS signal channel session		Figure 14: POST to convey the DOTS signal channel session
	configuration data.		configuration data.
	The parameters are described below:		The parameters are described below:
	session-id: Identifier for the DOTS signal channel session		session-id: Identifier for the DOTS signal channel session
	configuration data represented as an integer. This identifier		configuration data represented as an integer. This identifier
	MUST be generated by the DOTS client. This document does not make		MUST be generated by the DOTS client. This document does not make
	any assumption about how this identifier is generated. This is a		any assumption about how this identifier is generated. This is a
	mandatory attribute.		mandatory attribute.
	heartbeat-timeout: Heartbeat timeout is the time to wait for a		heartbeat-timeout: Heartbeat timeout is the time to wait for a
	response in milliseconds to check the DOTS peer health. This is		response in milliseconds to check the DOTS peer health. This is
	an optional attribute.		an optional attribute.
	max-retransmit: Maximum number of retransmissions for a message		max-retransmit: Maximum number of retransmissions for a message
	(referred to as MAX_RETRANSMIT parameter in CoAP). This is an		(referred to as MAX_RETRANSMIT parameter in CoAP). This is an
	optional attribute.		optional attribute.
	ack-timeout: Timeout value in seconds used to calculate the intial		ack-timeout: Timeout value in seconds used to calculate the initial
	retransmission timeout value (referred to as ACK_TIMEOUT parameter		retransmission timeout value (referred to as ACK_TIMEOUT parameter
	in CoAP). This is an optional attribute.		in CoAP). This is an optional attribute.
	ack-random-factor: Random factor used to influence the timing of		ack-random-factor: Random factor used to influence the timing of
	retransmissions (referred to as ACK_RANDOM_FACTOR parameter in		retransmissions (referred to as ACK_RANDOM_FACTOR parameter in
	CoAP). This is an optional attribute.		CoAP). This is an optional attribute.
	In the POST request at least one of the attributes heartbeat-timeout		In the POST request at least one of the attributes heartbeat-timeout
	or max-retransmit or ack-timeout or ack-random-factor MUST be		or max-retransmit or ack-timeout or ack-random-factor MUST be
	present. The POST request with higher numeric session-id value over-		present. The POST request with higher numeric session-id value over-
	rides the DOTS signal channel session configuration data installed by		rides the DOTS signal channel session configuration data installed by
	a POST request with a lower numeric session-id value.		a POST request with a lower numeric session-id value.
	skipping to change at page 30, line 31 ¶		skipping to change at page 30, line 31 ¶
	Redirected Signaling is discussed in detail in Section 3.2.2 of		Redirected Signaling is discussed in detail in Section 3.2.2 of
	[I-D.ietf-dots-architecture]. If the DOTS server wants to redirect		[I-D.ietf-dots-architecture]. If the DOTS server wants to redirect
	the DOTS client to an alternative DOTS server for a signaling session		the DOTS client to an alternative DOTS server for a signaling session
	then the response code 3.00 (alternate server) will be returned in		then the response code 3.00 (alternate server) will be returned in
	the response to the client. The DOTS server can return the error		the response to the client. The DOTS server can return the error
	response code 3.00 in response to a POST or PUT request from the DOTS		response code 3.00 in response to a POST or PUT request from the DOTS
	client or convey the error response code 3.00 in a unidirectional		client or convey the error response code 3.00 in a unidirectional
	notification response from the DOTS server.		notification response from the DOTS server.
	The DOTS server in the error response conveys the alternate DOTS		The DOTS server in the error response conveys the alternate DOTS
	server FQDN, and the alternate DOTS server IP addresses and TTL (time		server FQDN, and the alternate DOTS server IP addresses and time to
	to live) values in the CBOR body.		live values in the CBOR body.
	{		{
	"alt-server": "string",		"alt-server": "string",
	"alt-server-record": [		"alt-server-record": [
	{		{
	"addr": "string",		"addr": "string",
	"TTL" : integer,		"ttl" : integer,
	}		}
	]		]
	}		}
	Figure 19: Error response body		Figure 19: Error response body
	The parameters are described below:		The parameters are described below:
	alt-server: FQDN of alternate DOTS server.		alt-server: FQDN of alternate DOTS server.
	addr: IP address of alternate DOTS server.		addr: IP address of alternate DOTS server.
	TTL: Time to live represented as an integer number of seconds.
			ttl: Time to live (TTL) represented as an integer number of seconds.
	Figure 20 shows a 3.00 response example to convey the DOTS alternate		Figure 20 shows a 3.00 response example to convey the DOTS alternate
	server www.example-alt.com, its IP addresses 2002:db8:6401::1 and		server www.example-alt.com, its IP addresses 2001:db8:6401::1 and
	2002:db8:6401::2, and TTL values 3600 and 1800.		2001:db8:6401::2, and TTL values 3600 and 1800.
	{		{
	"alt-server": "www.example-alt.com",		"alt-server": "www.example-alt.com",
	"alt-server-record": [		"alt-server-record": [
	{		{
	"TTL" : 3600,		"ttl" : 3600,
	"addr": "2002:db8:6401::1"		"addr": "2001:db8:6401::1"
	},		},
	{		{
	"TTL" : 1800,		"ttl" : 1800,
	"addr": "2002:db8:6401::2"		"addr": "2001:db8:6401::2"
	}		}
	]		]
	}		}
	Figure 20: Example of error response body		Figure 20: Example of error response body
	When the DOTS client receives 3.00 response, it considers the current		When the DOTS client receives 3.00 response, it considers the current
	request as having failed, but SHOULD try the request with the		request as having failed, but SHOULD try the request with the
	alternate DOTS server. During a DDOS attack, the DNS server may be		alternate DOTS server. During a DDOS attack, the DNS server may be
	subjected to DDOS attack, alternate DOTS server IP addresses conveyed		subjected to DDOS attack, alternate DOTS server IP addresses conveyed
	skipping to change at page 32, line 21 ¶		skipping to change at page 32, line 21 ¶
	| Parameter name | CBOR key | CBOR major type of value |		| Parameter name | CBOR key | CBOR major type of value |
	|--------------------+------------------------+--------------------------|		|--------------------+------------------------+--------------------------|
	| mitigation-scope | 1 | 5 (map) |		| mitigation-scope | 1 | 5 (map) |
	| scope | 2 | 5 (map) |		| scope | 2 | 5 (map) |
	| mitigation-id | 3 | 0 (unsigned) |		| mitigation-id | 3 | 0 (unsigned) |
	| target-ip | 4 | 4 (array) |		| target-ip | 4 | 4 (array) |
	| target-port-range | 5 | 4 |		| target-port-range | 5 | 4 |
	| lower-port | 6 | 0 |		| lower-port | 6 | 0 |
	| upper-port | 7 | 0 |		| upper-port | 7 | 0 |
	| target-protocol | 8 | 4 |		| target-protocol | 8 | 4 |
	| FQDN | 9 | 4 |		| fqdn | 9 | 4 |
	| URI | 10 | 4 |		| uri | 10 | 4 |
	| alias | 11 | 4 |		| alias | 11 | 4 |
	| lifetime | 12 | 0 |		| lifetime | 12 | 0 |
	| attack-status | 13 | 0 |		| attack-status | 13 | 0 |
	| signal-config | 14 | 5 |		| signal-config | 14 | 5 |
	| heartbeat-timeout | 15 | 0 |		| heartbeat-timeout | 15 | 0 |
	| max-retransmit | 16 | 0 |		| max-retransmit | 16 | 0 |
	| ack-timeout | 17 | 0 |		| ack-timeout | 17 | 0 |
	| ack-random-factor | 18 | 7 |		| ack-random-factor | 18 | 7 |
	| MinValue | 19 | 0 |		| MinValue | 19 | 0 |
	| MaxValue | 20 | 0 |		| MaxValue | 20 | 0 |
	skipping to change at page 41, line 8 ¶		skipping to change at page 41, line 8 ¶
	o Parameter Name: session-id		o Parameter Name: session-id
	o CBOR Key Value: 26		o CBOR Key Value: 26
	o CBOR Major Type: 0		o CBOR Major Type: 0
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): this document		o Specification Document(s): this document
	11. Implementation Status		11. Implementation Status
	[Note to RFC Editor: Please remove this section and reference to		[Note to RFC Editor: Please remove this section and reference to
	[RFC6982] prior to publication.]		[RFC7942] prior to publication.]
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC6982].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their		be construed to be, a catalog of available implementations or their
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	According to [RFC6982], "this will allow reviewers and working groups		According to [RFC7942], "this will allow reviewers and working groups
	to assign due consideration to documents that have the benefit of		to assign due consideration to documents that have the benefit of
	running code, which may serve as evidence of valuable experimentation		running code, which may serve as evidence of valuable experimentation
	and feedback that have made the implemented protocols more mature.		and feedback that have made the implemented protocols more mature.
	It is up to the individual working groups to use this information as		It is up to the individual working groups to use this information as
	they see fit".		they see fit".
	11.1. nttdots		11.1. nttdots
	Organization: NTT Communication is developing a DOTS client and		Organization: NTT Communication is developing a DOTS client and
	DOTS server software based on DOTS signal channel specified in		DOTS server software based on DOTS signal channel specified in
	skipping to change at page 43, line 9 ¶		skipping to change at page 43, line 9 ¶
	Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States		Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States
	Email: rgm@htt-consult.com		Email: rgm@htt-consult.com
	Dan Wing Email: dwing-ietf@fuggles.com		Dan Wing Email: dwing-ietf@fuggles.com
	14. Acknowledgements		14. Acknowledgements
	Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen,		Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen,
	Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka,		Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka,
	Dave Dolson and Gilbert Clark for the discussion and comments.		Dave Dolson, Liang Xia and Gilbert Clark for the discussion and
			comments.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-core-coap-tcp-tls]		[I-D.ietf-core-coap-tcp-tls]
	Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, "CoAP (Constrained		Silverajan, B., and B. Raymor, "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	draft-ietf-core-coap-tcp-tls-07 (work in progress), March		draft-ietf-core-coap-tcp-tls-09 (work in progress), May
	2017.		2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	skipping to change at page 44, line 34 ¶		skipping to change at page 44, line 34 ¶
	Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.		Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
	Minaburo, "CBOR Encoding of Data Modeled with YANG",		Minaburo, "CBOR Encoding of Data Modeled with YANG",
	draft-ietf-core-yang-cbor-04 (work in progress), February		draft-ietf-core-yang-cbor-04 (work in progress), February
	2017.		2017.
	[I-D.ietf-dots-architecture]		[I-D.ietf-dots-architecture]
	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-01 (work in progress), October 2016.		architecture-03 (work in progress), June 2017.
			[I-D.ietf-dots-data-channel]
			Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
			P., Mortensen, A., and N. Teague, "Distributed Denial-of-
			Service Open Threat Signaling (DOTS) Data Channel", draft-
			ietf-dots-data-channel-01 (work in progress), June 2017.
	[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-04 (work in		Requirements", draft-ietf-dots-requirements-05 (work in
	progress), March 2017.		progress), June 2017.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,		Dobbins, R., Fouant, S., Migault, D., 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-04 (work		Open Threat Signaling (DDoS) Open Threat Signaling",
	in progress), March 2017.		draft-ietf-dots-use-cases-05 (work in progress), May 2017.
	[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-19 (work in progress),		Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
	March 2017.		April 2017.
	[I-D.ietf-tsvwg-rfc5405bis]
	Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in
	progress), October 2016.
	[I-D.reddy-dots-data-channel]
	Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
	P., Mortensen, A., and N. Teague, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel", draft-
	reddy-dots-data-channel-05 (work in progress), March 2017.
	[I-D.rescorla-tls-dtls13]		[I-D.rescorla-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-rescorla-tls-dtls13-01 (work in progress),		1.3", draft-rescorla-tls-dtls13-01 (work in progress),
	March 2017.		March 2017.
	[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,
	<http://www.rfc-editor.org/info/rfc791>.		<http://www.rfc-editor.org/info/rfc791>.
	skipping to change at page 46, line 10 ¶		skipping to change at page 46, line 5 ¶
	[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with		[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
	Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April		Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
	2012, <http://www.rfc-editor.org/info/rfc6555>.		2012, <http://www.rfc-editor.org/info/rfc6555>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<http://www.rfc-editor.org/info/rfc6724>.		<http://www.rfc-editor.org/info/rfc6724>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982,
	DOI 10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <http://www.rfc-editor.org/info/rfc7049>.		October 2013, <http://www.rfc-editor.org/info/rfc7049>.
	[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,		Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
	<http://www.rfc-editor.org/info/rfc7413>.		<http://www.rfc-editor.org/info/rfc7413>.
			[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
			NETCONF Protocol over Transport Layer Security (TLS) with
			Mutual X.509 Authentication", RFC 7589,
			DOI 10.17487/RFC7589, June 2015,
			<http://www.rfc-editor.org/info/rfc7589>.
	[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport		[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", RFC 7918,		Layer Security (TLS) False Start", RFC 7918,
	DOI 10.17487/RFC7918, August 2016,		DOI 10.17487/RFC7918, August 2016,
	<http://www.rfc-editor.org/info/rfc7918>.		<http://www.rfc-editor.org/info/rfc7918>.
	[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,
	<http://www.rfc-editor.org/info/rfc7924>.		<http://www.rfc-editor.org/info/rfc7924>.
			[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", BCP 205,
			RFC 7942, DOI 10.17487/RFC7942, July 2016,
			<http://www.rfc-editor.org/info/rfc7942>.
			[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
			Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
			March 2017, <http://www.rfc-editor.org/info/rfc8085>.
	Authors' Addresses		Authors' Addresses
	Tirumaleswar Reddy		Tirumaleswar Reddy
	Cisco Systems, Inc.		McAfee, Inc.
	Cessna Business Park, Varthur Hobli		Embassy Golf Link Business Park
	Sarjapur Marathalli Outer Ring Road		Bangalore, Karnataka 560071
	Bangalore, Karnataka 560103
	India		India
	Email: kondtir@gmail.com		Email: kondtir@gmail.com
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	Rennes 35000		Rennes 35000
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Prashanth Patil		Prashanth Patil
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: praspati@cisco.com		Email: praspati@cisco.com
	Andrew Mortensen		Andrew Mortensen
	Arbor Networks, Inc.		Arbor Networks, Inc.
	2727 S. State St		2727 S. State St
	Ann Arbor, MI 48104		Ann Arbor, MI 48104
	United States		United States
End of changes. 69 change blocks.
	107 lines changed or deleted		135 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/