< draft-ietf-dots-telemetry-11.txt		draft-ietf-dots-telemetry-12.txt >
	DOTS M. Boucadair, Ed.		DOTS M. Boucadair, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy, Ed.		Intended status: Standards Track T. Reddy, Ed.
	Expires: January 28, 2021 McAfee		Expires: April 1, 2021 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	July 27, 2020		September 28, 2020
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-11		draft-ietf-dots-telemetry-12
	Abstract		Abstract
	This document aims to enrich DOTS signal channel protocol with		This document aims to enrich DOTS signal channel protocol with
	various telemetry attributes allowing optimal Distributed Denial-of-		various telemetry attributes allowing optimal Distributed Denial-of-
	Service attack mitigation. It specifies the normal traffic baseline		Service attack mitigation. It specifies the normal traffic baseline
	and attack traffic telemetry attributes a DOTS client can convey to		and attack traffic telemetry attributes a DOTS client can convey to
	its DOTS server in the mitigation request, the mitigation status		its DOTS server in the mitigation request, the mitigation status
	telemetry attributes a DOTS server can communicate to a DOTS client,		telemetry attributes a DOTS server can communicate to a DOTS client,
	and the mitigation efficacy telemetry attributes a DOTS client can		and the mitigation efficacy telemetry attributes a DOTS client can
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 28, 2021.		This Internet-Draft will expire on April 1, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 ¶
	4.2.4. Controlling Configuration Data . . . . . . . . . . . 10		4.2.4. Controlling Configuration Data . . . . . . . . . . . 10
	4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11		4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11
	4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11		4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11
	4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 11		4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 11
	4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 12		4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 12
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 12		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 12
	6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 13		6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 13
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 14		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 14
	6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 14		6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 14
	6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16		6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16
	6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 20		6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19
	6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20		6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20
	6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 21		6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20
	6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 22		6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21
	6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27		6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27
	6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27
	6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 28		6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27
	6.3.1. Convey DOTS Client Domain Baseline Information . . . 31		6.3.1. Convey DOTS Client Domain Baseline Information . . . 30
	6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 34		6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33
	6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 34		6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33
	6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 34		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 34		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33
	7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 35		7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 37		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36
	7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 38		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 37
	7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 39		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38
	7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 40		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39
	7.1.4. Total Attack Connections . . . . . . . . . . . . . . 42		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41
	7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 45		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 44
	7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 51		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 50
	7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 54		7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 53
	8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 59		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 58
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
	Telemetry Attributes . . . . . . . . . . . . . . . . . . 59		Telemetry Attributes . . . . . . . . . . . . . . . . . . 58
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 61		Attributes . . . . . . . . . . . . . . . . . . . . . . . 60
	9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 65		9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 64
	10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 65		10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 64
	10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 65		10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 64
	10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 93		10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 92
	11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 96		11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 95
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
	12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 98		12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 97
	12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 101		12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 100
	12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 101		12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 100
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 102		13. Security Considerations . . . . . . . . . . . . . . . . . . . 101
	13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 102		13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 101
	13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 103		13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 102
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 104		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 103
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 104		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 103
	16.1. Normative References . . . . . . . . . . . . . . . . . . 104		16.1. Normative References . . . . . . . . . . . . . . . . . . 103
	16.2. Informative References . . . . . . . . . . . . . . . . . 106		16.2. Informative References . . . . . . . . . . . . . . . . . 105
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
	1. Introduction		1. Introduction
	Distributed Denial of Service (DDoS) attacks have become more		Distributed Denial of Service (DDoS) attacks have become more
	sophisticated. IT organizations and service providers are facing		sophisticated. IT organizations and service providers are facing
	DDoS attacks that fall into two broad categories:		DDoS attacks that fall into two broad categories:
	1. Network/Transport layer attacks target the victim's		1. Network/Transport layer attacks target the victim's
	infrastructure. These attacks are not necessarily aimed at		infrastructure. These attacks are not necessarily aimed at
	taking down the actual delivered services, but rather to		taking down the actual delivered services, but rather to
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	The conclusion derived from these real scenarios is that modern		The conclusion derived from these real scenarios is that modern
	attacks detection and mitigation are most certainly complicated and		attacks detection and mitigation are most certainly complicated and
	highly convoluted tasks. They demand a comprehensive knowledge of		highly convoluted tasks. They demand a comprehensive knowledge of
	the attack attributes, the targeted normal behavior (including,		the attack attributes, the targeted normal behavior (including,
	normal traffic patterns), as well as the attacker's on-going and past		normal traffic patterns), as well as the attacker's on-going and past
	actions. Even more challenging, retrieving all the analytics needed		actions. Even more challenging, retrieving all the analytics needed
	for detecting these attacks is not simple to obtain with the		for detecting these attacks is not simple to obtain with the
	industry's current capabilities.		industry's current capabilities.
	The DOTS signal channel protocol [I-D.boucadair-dots-rfc8782-bis] is		The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used
	used to carry information about a network resource or a network (or a		to carry information about a network resource or a network (or a part
	part thereof) that is under a DDoS attack. Such information is sent		thereof) that is under a DDoS attack. Such information is sent by a
	by a DOTS client to one or multiple DOTS servers so that appropriate		DOTS client to one or multiple DOTS servers so that appropriate
	mitigation actions are undertaken on traffic deemed suspicious.		mitigation actions are undertaken on traffic deemed suspicious.
	Various use cases are discussed in [I-D.ietf-dots-use-cases].		Various use cases are discussed in [I-D.ietf-dots-use-cases].
	Typically, DOTS clients can be integrated within a DDoS attack		Typically, DOTS clients can be integrated within a DDoS attack
	detector, or network and security elements that have been actively		detector, or network and security elements that have been actively
	engaged with ongoing attacks. The DOTS client mitigation environment		engaged with ongoing attacks. The DOTS client mitigation environment
	determines that it is no longer possible or practical for it to		determines that it is no longer possible or practical for it to
	handle these attacks. This can be due to a lack of resources or		handle these attacks. This can be due to a lack of resources or
	security capabilities, as derived from the complexities and the		security capabilities, as derived from the complexities and the
	intensity of these attacks. In this circumstance, the DOTS client		intensity of these attacks. In this circumstance, the DOTS client
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	DOTS server is handling normal and attack traffic attributes, and		DOTS server is handling normal and attack traffic attributes, and
	mitigation hints is implementation specific.		mitigation hints is implementation specific.
	Both DOTS clients and servers can benefit this information by		Both DOTS clients and servers can benefit this information by
	presenting various information in relevant management, reporting, and		presenting various information in relevant management, reporting, and
	portal systems.		portal systems.
	This document defines DOTS telemetry attributes that can be conveyed		This document defines DOTS telemetry attributes that can be conveyed
	by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry		by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
	attributes are not mandatory attributes of the DOTS signal channel		attributes are not mandatory attributes of the DOTS signal channel
	protocol [I-D.boucadair-dots-rfc8782-bis]. Nevertheless, when DOTS		protocol [I-D.ietf-dots-rfc8782-bis]. Nevertheless, when DOTS
	telemetry attributes are available to a DOTS agent, and absent any		telemetry attributes are available to a DOTS agent, and absent any
	policy, it can signal the attributes in order to optimize the overall		policy, it can signal the attributes in order to optimize the overall
	mitigation service provisioned using DOTS.		mitigation service provisioned using DOTS.
	2. Terminology		2. 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 48 ¶
	[I-D.ietf-dots-signal-filter-control] even when the pipe is		[I-D.ietf-dots-signal-filter-control] even when the pipe is
	overwhelmed.		overwhelmed.
	4. Design Overview		4. Design Overview
	4.1. Overview of Telemetry Operations		4.1. Overview of Telemetry Operations
	This document specifies an extension to the DOTS signal channel		This document specifies an extension to the DOTS signal channel
	protocol. Considerations about how to establish, maintain, and make		protocol. Considerations about how to establish, maintain, and make
	use of the DOTS signal channel are specified in		use of the DOTS signal channel are specified in
	[I-D.boucadair-dots-rfc8782-bis].		[I-D.ietf-dots-rfc8782-bis].
	Once the DOTS signal channel is established, DOTS clients that		Once the DOTS signal channel is established, DOTS clients that
	support the DOTS telemetry extension proceed with the telemetry setup		support the DOTS telemetry extension proceed with the telemetry setup
	configuration (e.g., measurement interval, telemetry notification		configuration (e.g., measurement interval, telemetry notification
	interface, pipe capacity, normal traffic baseline) as detailed in		interface, pipe capacity, normal traffic baseline) as detailed in
	Section 6. DOTS agents can then include DOTS telemetry attributes		Section 6. DOTS agents can then include DOTS telemetry attributes
	using the DOTS signal channel (Section 7.1). Typically, a DOTS		using the DOTS signal channel (Section 7.1). Typically, a DOTS
	client can use separate messages to share with its DOTS server(s) a		client can use separate messages to share with its DOTS server(s) a
	set of telemetry data bound to an ongoing mitigation (Section 7.2).		set of telemetry data bound to an ongoing mitigation (Section 7.2).
	Also, a DOTS client that is interested to receive telemetry		Also, a DOTS client that is interested to receive telemetry
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	mitigation request if the notified attack cannot be mitigated locally		mitigation request if the notified attack cannot be mitigated locally
	within the DOTS client domain.		within the DOTS client domain.
	Aggregate DOTS telemetry data can also be included in efficacy update		Aggregate DOTS telemetry data can also be included in efficacy update
	(Section 8.1) or mitigation update (Section 8.2) messages.		(Section 8.1) or mitigation update (Section 8.2) messages.
	4.2. Generic Considerations		4.2. Generic Considerations
	4.2.1. DOTS Client Identification		4.2.1. DOTS Client Identification
	Following the rules in Section 5.4.1 of		Following the rules in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis],
	[I-D.boucadair-dots-rfc8782-bis], a unique identifier is generated by		a unique identifier is generated by a DOTS client to prevent request
	a DOTS client to prevent request collisions ('cuid').		collisions ('cuid').
	As a reminder, [I-D.boucadair-dots-rfc8782-bis] forbids 'cuid' to be		As a reminder, [I-D.ietf-dots-rfc8782-bis] forbids 'cuid' to be
	returned in a response message body.		returned in a response message body.
	4.2.2. DOTS Gateways		4.2.2. DOTS Gateways
	DOTS gateways may be located between DOTS clients and servers. The		DOTS gateways may be located between DOTS clients and servers. The
	considerations elaborated in Section 5.4.1 of		considerations elaborated in Section 4.4.1 of
	[I-D.boucadair-dots-rfc8782-bis] must be followed. In particular,		[I-D.ietf-dots-rfc8782-bis] must be followed. In particular, 'cdid'
	'cdid' attribute is used to unambiguously identify a DOTS client		attribute is used to unambiguously identify a DOTS client domain.
	domain.
	As a reminder, [I-D.boucadair-dots-rfc8782-bis] forbids 'cdid' (if		As a reminder, [I-D.ietf-dots-rfc8782-bis] forbids 'cdid' (if
	present) to be returned in a response message body.		present) to be returned in a response message body.
	4.2.3. Empty URI Paths		4.2.3. Empty URI Paths
	Uri-Path parameters and attributes with empty values MUST NOT be		Uri-Path parameters and attributes with empty values MUST NOT be
	present in a request and render an entire message invalid.		present in a request and render an entire message invalid.
	4.2.4. Controlling Configuration Data		4.2.4. Controlling Configuration Data
	The DOTS server follows the same considerations discussed in		The DOTS server follows the same considerations discussed in
	Section of 5.5.3 of [I-D.boucadair-dots-rfc8782-bis] for managing		Section of 4.5.3 of [I-D.ietf-dots-rfc8782-bis] for managing DOTS
	DOTS telemetry configuration freshness and notification.		telemetry configuration freshness and notification.
	Likewise, a DOTS client may control the selection of configuration		Likewise, a DOTS client may control the selection of configuration
	and non-configuration data nodes when sending a GET request by means		and non-configuration data nodes when sending a GET request by means
	of the 'c' Uri-Query option and following the procedure specified in		of the 'c' Uri-Query option and following the procedure specified in
	Section of 5.4.2 of [I-D.boucadair-dots-rfc8782-bis]. These		Section of 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. These
	considerations are not reiterated in the following sections.		considerations are not reiterated in the following sections.
	4.3. Block-wise Transfer		4.3. Block-wise Transfer
	DOTS clients can use block wise transfer [RFC7959] with the		DOTS clients can use block wise transfer [RFC7959] with the
	recommendation detailed in Section 5.4.2 of		recommendation detailed in Section 4.4.2 of
	[I-D.boucadair-dots-rfc8782-bis] to control the size of a response		[I-D.ietf-dots-rfc8782-bis] to control the size of a response when
	when the data to be returned does not fit within a single datagram.		the data to be returned does not fit within a single datagram.
	DOTS clients can also use CoAP Block1 Option in a PUT request (see		DOTS clients can also use CoAP Block1 Option in a PUT request (see
	Section 2.5 of [RFC7959]) to initiate large transfers, but these		Section 2.5 of [RFC7959]) to initiate large transfers, but these
	Block1 transfers will fail if the inbound "pipe" is running full, so		Block1 transfers will fail if the inbound "pipe" is running full, so
	consideration needs to be made to try to fit this PUT into a single		consideration needs to be made to try to fit this PUT into a single
	transfer, or to separate out the PUT into several discrete PUTs where		transfer, or to separate out the PUT into several discrete PUTs where
	each of them fits into a single packet.		each of them fits into a single packet.
	Block3 and Block 4 Options that are similar to the CoAP Block1 and		Block3 and Block 4 Options that are similar to the CoAP Block1 and
	Block2 Options, but enable faster transmissions of big blocks of data		Block2 Options, but enable faster transmissions of big blocks of data
	with less packet interchanges, are defined in		with less packet interchanges, are defined in
	[I-D.bosh-core-new-block]. DOTS implementations can consider the use		[I-D.ietf-core-new-block]. DOTS implementations can consider the use
	of Block3 and Block 4 Options.		of Block3 and Block 4 Options.
	4.4. DOTS Multi-homing Considerations		4.4. DOTS Multi-homing Considerations
	Multi-homed DOTS clients are assumed to follow the recommendations in		Multi-homed DOTS clients are assumed to follow the recommendations in
	[I-D.ietf-dots-multihoming] to select which DOTS server to contact		[I-D.ietf-dots-multihoming] to select which DOTS server to contact
	and which IP prefixes to include in a telemetry message to a given		and which IP prefixes to include in a telemetry message to a given
	peer DOTS server. For example, if each upstream network exposes a		peer DOTS server. For example, if each upstream network exposes a
	DOTS server and the DOTS client maintains DOTS channels with all of		DOTS server and the DOTS client maintains DOTS channels with all of
	them, only the information related to prefixes assigned by an		them, only the information related to prefixes assigned by an
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 32 ¶
	Examples are provided for illustration purposes. The document does		Examples are provided for illustration purposes. The document does
	not aim to provide a comprehensive list of message examples.		not aim to provide a comprehensive list of message examples.
	The authoritative reference for validating telemetry messages is the		The authoritative reference for validating telemetry messages is the
	YANG module (Section 10.1) and the mapping table established in		YANG module (Section 10.1) and the mapping table established in
	Section 11.		Section 11.
	5. Telemetry Operation Paths		5. Telemetry Operation Paths
	As discussed in Section 5.2 of [I-D.boucadair-dots-rfc8782-bis], each		As discussed in Section 4.2 of [I-D.ietf-dots-rfc8782-bis], each DOTS
	DOTS operation is indicated by a path suffix that indicates the		operation is indicated by a path suffix that indicates the intended
	intended operation. The operation path is appended to the path		operation. The operation path is appended to the path prefix to form
	prefix to form the URI used with a CoAP request to perform the		the URI used with a CoAP request to perform the desired DOTS
	desired DOTS operation. The following telemetry path suffixes are		operation. The following telemetry path suffixes are defined
	defined (Table 1):		(Table 1):
	+-----------------+----------------+-----------+		+-----------------+----------------+-----------+
	| Operation | Operation Path | Details |		| Operation | Operation Path | Details |
	+=================+================+===========+		+=================+================+===========+
	| Telemetry Setup | /tm-setup | Section 6 |		| Telemetry Setup | /tm-setup | Section 6 |
	| Telemetry | /tm | Section 7 |		| Telemetry | /tm | Section 7 |
	+-----------------+----------------+-----------+		+-----------------+----------------+-----------+
	Table 1: DOTS Telemetry Operations		Table 1: DOTS Telemetry Operations
	skipping to change at page 17, line 40 ¶		skipping to change at page 17, line 16 ¶
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tsid: Telemetry Setup Identifier is an identifier for the DOTS		tsid: Telemetry Setup Identifier is an identifier for the DOTS
	telemetry setup configuration data represented as an integer.		telemetry setup configuration data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tsid'		This identifier MUST be generated by DOTS clients. 'tsid'
	values MUST increase monotonically (when a new PUT is generated		values MUST increase monotonically (when a new PUT is generated
	by a DOTS client to convey new configuration parameters for the		by a DOTS client to convey new configuration parameters for the
	telemetry).		telemetry).
	The procedure specified in Section 5.4.1 of		The procedure specified in Section 4.4.1 of
	[I-D.boucadair-dots-rfc8782-bis] MUST be followed for 'tsid'		[I-D.ietf-dots-rfc8782-bis] MUST be followed for 'tsid'
	rollover.		rollover.
	This is a mandatory attribute. 'tsid' MUST follow 'cuid'.		This is a mandatory attribute. 'tsid' MUST follow 'cuid'.
	'cuid' and 'tsid' MUST NOT appear in the PUT request message body.		'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
	At least one configurable attribute MUST be present in the PUT		At least one configurable attribute MUST be present in the PUT
	request.		request.
	The PUT request with a higher numeric 'tsid' value overrides the DOTS		The PUT request with a higher numeric 'tsid' value overrides the DOTS
	skipping to change at page 34, line 42 ¶		skipping to change at page 33, line 42 ¶
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 21: Delete Telemetry Configuration		Figure 21: Delete Telemetry Configuration
	6.5. Conflict with Other DOTS Clients of the Same Domain		6.5. Conflict with Other DOTS Clients of the Same Domain
	A DOTS server may detect conflicts between requests to convey pipe		A DOTS server may detect conflicts between requests to convey pipe
	and baseline information received from DOTS clients of the same DOTS		and baseline information received from DOTS clients of the same DOTS
	client domain. 'conflict-information' is used to report the conflict		client domain. 'conflict-information' is used to report the conflict
	to the DOTS client following similar conflict handling discussed in		to the DOTS client following similar conflict handling discussed in
	Section 5.4.1 of [I-D.boucadair-dots-rfc8782-bis]. The conflict		Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]. The conflict cause can
	cause can be set to one of these values:		be set to one of these values:
	1: Overlapping targets (Section 5.4.1 of		1: Overlapping targets (Section 4.4.1 of
	[I-D.boucadair-dots-rfc8782-bis]).		[I-D.ietf-dots-rfc8782-bis]).
	TBA: Overlapping pipe scope (see Section 12).		TBA: Overlapping pipe scope (see Section 12).
	7. DOTS Pre-or-Ongoing Mitigation Telemetry		7. DOTS Pre-or-Ongoing Mitigation Telemetry
	There are two broad types of DDoS attacks, one is bandwidth consuming		There are two broad types of DDoS attacks, one is bandwidth consuming
	attack, the other is target resource consuming attack. This section		attack, the other is target resource consuming attack. This section
	outlines the set of DOTS telemetry attributes (Section 7.1) that		outlines the set of DOTS telemetry attributes (Section 7.1) that
	covers both the types of attacks. The objective of these attributes		covers both the types of attacks. The objective of these attributes
	is to allow for the complete knowledge of attacks and the various		is to allow for the complete knowledge of attacks and the various
	skipping to change at page 36, line 20 ¶		skipping to change at page 35, line 20 ¶
	| |		| |
	|=========Mitigation Request (target-prefix)===========>|		|=========Mitigation Request (target-prefix)===========>|
	| |		| |
	Figure 23: Example of Request Correlation using Target Prefix		Figure 23: Example of Request Correlation using Target Prefix
	DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry		DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
	notifications to the same peer more frequently than once every		notifications to the same peer more frequently than once every
	'telemetry-notify-interval' (Section 6.1). If a telemetry		'telemetry-notify-interval' (Section 6.1). If a telemetry
	notification is sent using a block-like transfer mechanism (e.g.,		notification is sent using a block-like transfer mechanism (e.g.,
	[I-D.bosh-core-new-block]), this rate limit policy MUST NOT consider		[I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider
	these individual blocks as separate notifications, but as a single		these individual blocks as separate notifications, but as a single
	notification.		notification.
	DOTS pre-or-ongoing-mitigation telemetry request and response		DOTS pre-or-ongoing-mitigation telemetry request and response
	messages MUST be marked as Non-Confirmable messages (Section 2.1 of		messages MUST be marked as Non-Confirmable messages (Section 2.1 of
	[RFC7252]).		[RFC7252]).
	structure dots-telemetry:		structure dots-telemetry:
	+-- (telemetry-message-type)?		+-- (telemetry-message-type)?
	+--:(telemetry-setup)		+--:(telemetry-setup)
	skipping to change at page 48, line 31 ¶		skipping to change at page 47, line 31 ¶
	telemetry information using the vendor mapping(s) that it provided to		telemetry information using the vendor mapping(s) that it provided to
	the DOTS server and the DOTS server SHOULD use the vendor mappings(s)		the DOTS server and the DOTS server SHOULD use the vendor mappings(s)
	provided to the DOTS client when transmitting telemetry data to peer		provided to the DOTS client when transmitting telemetry data to peer
	DOTS agent.		DOTS agent.
	The "ietf-dots-mapping" YANG module defined in Section 10.2 augments		The "ietf-dots-mapping" YANG module defined in Section 10.2 augments
	the "ietf-dots-data-channel" [RFC8783]. The tree structure of this		the "ietf-dots-data-channel" [RFC8783]. The tree structure of this
	module is shown in Figure 30.		module is shown in Figure 30.
	module: ietf-dots-mapping		module: ietf-dots-mapping
	augment /ietf-data:dots-data/ietf-data:dots-client:		augment /data-channel:dots-data/data-channel:dots-client:
	+--rw vendor-mapping {dots-telemetry}?		+--rw vendor-mapping {dots-telemetry}?
	+--rw vendor* [vendor-id]		+--rw vendor* [vendor-id]
	+--rw vendor-id uint32		+--rw vendor-id uint32
	+--rw vendor-name? string		+--rw vendor-name? string
	+--rw last-updated uint64		+--rw last-updated uint64
	+--rw attack-mapping* [attack-id]		+--rw attack-mapping* [attack-id]
	+--rw attack-id uint32		+--rw attack-id uint32
	+--rw attack-description string		+--rw attack-description string
	augment /ietf-data:dots-data/ietf-data:capabilities:		augment /data-channel:dots-data/data-channel:capabilities:
	+--ro vendor-mapping-enabled? boolean {dots-telemetry}?		+--ro vendor-mapping-enabled? boolean {dots-telemetry}?
	augment /ietf-data:dots-data:		augment /data-channel:dots-data:
	+--ro vendor-mapping {dots-telemetry}?		+--ro vendor-mapping {dots-telemetry}?
	+--ro vendor* [vendor-id]		+--ro vendor* [vendor-id]
	+--ro vendor-id uint32		+--ro vendor-id uint32
	+--ro vendor-name? string		+--ro vendor-name? string
	+--ro last-updated uint64		+--ro last-updated uint64
	+--ro attack-mapping* [attack-id]		+--ro attack-mapping* [attack-id]
	+--ro attack-id uint32		+--ro attack-id uint32
	+--ro attack-description string		+--ro attack-description string
	Figure 30: Vendor Attack Mapping Tree Structure		Figure 30: Vendor Attack Mapping Tree Structure
	skipping to change at page 53, line 5 ¶		skipping to change at page 52, line 5 ¶
	'cuid' is a mandatory Uri-Path parameter for PUT requests.		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tmid: Telemetry Identifier is an identifier for the DOTS pre-or-		tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
	ongoing-mitigation telemetry data represented as an integer.		ongoing-mitigation telemetry data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tmid' values		This identifier MUST be generated by DOTS clients. 'tmid' values
	MUST increase monotonically (when a new PUT is generated by a		MUST increase monotonically (when a new PUT is generated by a
	DOTS client to convey pre-or-ongoing-mitigation telemetry).		DOTS client to convey pre-or-ongoing-mitigation telemetry).
	The procedure specified in Section 5.4.1 of		The procedure specified in Section 4.4.1 of
	[I-D.boucadair-dots-rfc8782-bis] MUST be followed for 'tmid'		[I-D.ietf-dots-rfc8782-bis] MUST be followed for 'tmid'
	rollover.		rollover.
	This is a mandatory attribute. 'tmid' MUST follow 'cuid'.		This is a mandatory attribute. 'tmid' MUST follow 'cuid'.
	'cuid' and 'tmid' MUST NOT appear in the PUT request message body.		'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
	At least 'target' attribute and another pre-or-ongoing-mitigation		At least 'target' attribute and another pre-or-ongoing-mitigation
	attributes (Section 7.1) MUST be present in the PUT request. If only		attributes (Section 7.1) MUST be present in the PUT request. If only
	the 'target' attribute is present, this request is handled as per		the 'target' attribute is present, this request is handled as per
	Section 7.3.		Section 7.3.
	skipping to change at page 57, line 26 ¶		skipping to change at page 56, line 26 ¶
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Query: "target-protocol=17"		Uri-Query: "target-protocol=17"
	Observe: 0		Observe: 0
	Figure 42: GET Request to Receive Telemetry Asynchronous		Figure 42: GET Request to Receive Telemetry Asynchronous
	Notifications Filtered using Uri-Query		Notifications Filtered using Uri-Query
	The DOTS server will send asynchronous notifications to the DOTS		The DOTS server will send asynchronous notifications to the DOTS
	client when an attack event is detected following similar		client when an attack event is detected following similar
	considerations as in Section 5.4.2.1 of		considerations as in Section 4.4.2.1 of [I-D.ietf-dots-rfc8782-bis].
	[I-D.boucadair-dots-rfc8782-bis]. An example of a pre-or-ongoing-		An example of a pre-or-ongoing-mitigation telemetry notification is
	mitigation telemetry notification is shown in Figure 43.		shown in Figure 43.
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"pre-or-ongoing-mitigation": [		"pre-or-ongoing-mitigation": [
	{		{
	"tmid": 567,		"tmid": 567,
	"target": {		"target": {
	"target-prefix": [		"target-prefix": [
	"2001:db8::1/128"		"2001:db8::1/128"
	]		]
	skipping to change at page 59, line 21 ¶		skipping to change at page 58, line 21 ¶
	mitigation telemetry data for a target MUST send a delete request		mitigation telemetry data for a target MUST send a delete request
	similar to the one depicted in Figure 37.		similar to the one depicted in Figure 37.
	8. DOTS Telemetry Mitigation Status Update		8. DOTS Telemetry Mitigation Status Update
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
	Attributes		Attributes
	The mitigation efficacy telemetry attributes can be signaled from		The mitigation efficacy telemetry attributes can be signaled from
	DOTS clients to DOTS servers as part of the periodic mitigation		DOTS clients to DOTS servers as part of the periodic mitigation
	efficacy updates to the server (Section 6.3.4 of		efficacy updates to the server (Section 4.4.3 of
	[I-D.boucadair-dots-rfc8782-bis]).		[I-D.ietf-dots-rfc8782-bis]).
	Total Attack Traffic: The overall attack traffic as observed from		Total Attack Traffic: The overall attack traffic as observed from
	the DOTS client perspective during an active mitigation. See		the DOTS client perspective during an active mitigation. See
	Figure 27.		Figure 27.
	Attack Details: The overall attack details as observed from the		Attack Details: The overall attack details as observed from the
	DOTS client perspective during an active mitigation. See		DOTS client perspective during an active mitigation. See
	Section 7.1.5.		Section 7.1.5.
	The "ietf-dots-telemetry" YANG module (Section 10.1) augments the		The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
	'mitigation-scope' message type defined in "ietf-dots-signal"		'mitigation-scope' message type defined in "ietf-dots-signal"
	[I-D.boucadair-dots-rfc8782-bis] so that these attributes can be		[I-D.ietf-dots-rfc8782-bis] so that these attributes can be signalled
	signalled by a DOTS client in a mitigation efficacy update		by a DOTS client in a mitigation efficacy update (Figure 44).
	(Figure 44).
	augment-structure /signal:dots-signal/signal:message-type		augment-structure /dots-signal:dots-signal/dots-signal:message-type
	/signal:mitigation-scope/signal:scope:		/dots-signal:mitigation-scope/dots-signal:scope:
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	+-- vendor-id uint32		+-- vendor-id uint32
	+-- attack-id uint32		+-- attack-id uint32
	+-- attack-description? string		+-- attack-description? string
	skipping to change at page 61, line 42 ¶		skipping to change at page 60, line 42 ¶
	}		}
	Figure 45: An Example of Mitigation Efficacy Update with Telemetry		Figure 45: An Example of Mitigation Efficacy Update with Telemetry
	Attributes		Attributes
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes		Attributes
	The mitigation status telemetry attributes can be signaled from the		The mitigation status telemetry attributes can be signaled from the
	DOTS server to the DOTS client as part of the periodic mitigation		DOTS server to the DOTS client as part of the periodic mitigation
	status update (Section 6.3.3 of [I-D.boucadair-dots-rfc8782-bis]).		status update (Section 4.4.2.2 of [I-D.ietf-dots-rfc8782-bis]). In
	In particular, DOTS clients can receive asynchronous notifications of		particular, DOTS clients can receive asynchronous notifications of
	the attack details from DOTS servers using the Observe option defined		the attack details from DOTS servers using the Observe option defined
	in [RFC7641].		in [RFC7641].
	In order to make use of this feature, DOTS clients MUST establish a		In order to make use of this feature, DOTS clients MUST establish a
	telemetry setup session with the DOTS server in 'idle' time and MUST		telemetry setup session with the DOTS server in 'idle' time and MUST
	set the 'server-originated-telemetry' attribute to 'true'.		set the 'server-originated-telemetry' attribute to 'true'.
	DOTS servers MUST NOT include telemetry attributes in mitigation		DOTS servers MUST NOT include telemetry attributes in mitigation
	status updates sent to DOTS clients for which 'server-originated-		status updates sent to DOTS clients for which 'server-originated-
	telemetry' attribute is set to 'false'.		telemetry' attribute is set to 'false'.
	skipping to change at page 62, line 19 ¶		skipping to change at page 61, line 19 ¶
	As defined in [RFC8612], the actual mitigation activities can include		As defined in [RFC8612], the actual mitigation activities can include
	several countermeasure mechanisms. The DOTS server signals the		several countermeasure mechanisms. The DOTS server signals the
	current operational status of relevant countermeasures. A list of		current operational status of relevant countermeasures. A list of
	attacks detected by each countermeasure MAY also be included. The		attacks detected by each countermeasure MAY also be included. The
	same attributes defined in Section 7.1.5 are applicable for		same attributes defined in Section 7.1.5 are applicable for
	describing the attacks detected and mitigated at the DOTS server		describing the attacks detected and mitigated at the DOTS server
	domain.		domain.
	The "ietf-dots-telemetry" YANG module (Section 10.1) augments the		The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
	'mitigation-scope' message type defined in "ietf-dots-signal"		'mitigation-scope' message type defined in "ietf-dots-signal"
	[I-D.boucadair-dots-rfc8782-bis] with telemetry data as depicted in		[I-D.ietf-dots-rfc8782-bis] with telemetry data as depicted in the
	the following tree structure:		following tree structure:
	augment-structure /signal:dots-signal/signal:message-type		augment-structure /dots-signal:dots-signal/dots-signal:message-type
	/signal:mitigation-scope/signal:scope:		/dots-signal:mitigation-scope/dots-signal:scope:
	+-- (direction)?		+-- (direction)?
	| +--:(server-to-client-only)		| +--:(server-to-client-only)
	| +-- total-traffic* [unit]		| +-- total-traffic* [unit]
	| | +-- unit unit		| | +-- unit unit
	| | +-- low-percentile-g? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- mid-percentile-g? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- high-percentile-g? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- peak-g? yang:gauge64		| | +-- peak-g? yang:gauge64
	| +-- total-attack-connection		| +-- total-attack-connection
	| +-- low-percentile-c		| +-- low-percentile-c
	skipping to change at page 65, line 28 ¶		skipping to change at page 64, line 28 ¶
	using Uri-Query		using Uri-Query
	If the target query does not match the target of the enclosed 'mid'		If the target query does not match the target of the enclosed 'mid'
	as maintained by the DOTS server, the latter MUST respond with a 4.04		as maintained by the DOTS server, the latter MUST respond with a 4.04
	(Not Found) error Response Code. The DOTS server MUST NOT add a new		(Not Found) error Response Code. The DOTS server MUST NOT add a new
	observe entry if this query overlaps with an existing one.		observe entry if this query overlaps with an existing one.
	9. Error Handling		9. Error Handling
	A list of common CoAP errors that are implemented by DOTS servers are		A list of common CoAP errors that are implemented by DOTS servers are
	provided in Section 6 of [I-D.boucadair-dots-rfc8782-bis]. The		provided in Section 9 of [I-D.ietf-dots-rfc8782-bis]. The following
	following additional error cases apply for the telemetry extension:		additional error cases apply for the telemetry extension:
	o 4.00 (Bad Request) is returned by the DOTS server when the DOTS		o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
	client has sent a request that violates the DOTS telemetry		client has sent a request that violates the DOTS telemetry
	extension.		extension.
	o 4.04 (Not Found) is returned by the DOTS server when the DOTS		o 4.04 (Not Found) is returned by the DOTS server when the DOTS
	client is requesting a 'tsid' or 'tmid' that is not valid.		client is requesting a 'tsid' or 'tmid' that is not valid.
	o 4.00 (Bad Request) is returned by the DOTS server when the DOTS		o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
	client has sent a request with invalid query types (e.g., not		client has sent a request with invalid query types (e.g., not
	skipping to change at page 66, line 10 ¶		skipping to change at page 65, line 10 ¶
	This module uses types defined in [RFC6991] and [RFC8345].		This module uses types defined in [RFC6991] and [RFC8345].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-07-03.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2020-07-03.yang"
	module ietf-dots-telemetry {		module ietf-dots-telemetry {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
	prefix dots-telemetry;		prefix dots-telemetry;
	import ietf-dots-signal-channel {		import ietf-dots-signal-channel {
	prefix signal;		prefix dots-signal;
	reference		reference
	"RFC UUUU: Distributed Denial-of-Service Open Threat Signaling		"RFC UUUU: Distributed Denial-of-Service Open Threat Signaling
	(DOTS) Signal Channel Specification";		(DOTS) Signal Channel Specification";
	}		}
	import ietf-dots-data-channel {		import ietf-dots-data-channel {
	prefix ietf-data;		prefix data-channel;
	reference		reference
	"RFC 8783: Distributed Denial-of-Service Open Threat		"RFC 8783: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Data Channel Specification";		Signaling (DOTS) Data Channel Specification";
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference		reference
	"Section 3 of RFC 6991";		"Section 3 of RFC 6991";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	skipping to change at page 85, line 24 ¶		skipping to change at page 84, line 24 ¶
	description		description
	"Total attack connections issued from this source.";		"Total attack connections issued from this source.";
	uses connection-protocol-percentile;		uses connection-protocol-percentile;
	}		}
	}		}
	}		}
	grouping baseline {		grouping baseline {
	description		description
	"Grouping for the telemetry baseline.";		"Grouping for the telemetry baseline.";
	uses ietf-data:target;		uses data-channel:target;
	leaf-list alias-name {		leaf-list alias-name {
	type string;		type string;
	description		description
	"An alias name that points to a resource.";		"An alias name that points to a resource.";
	}		}
	list total-traffic-normal {		list total-traffic-normal {
	key "unit";		key "unit";
	description		description
	"Total traffic normal baselines.";		"Total traffic normal baselines.";
	uses traffic-unit;		uses traffic-unit;
	skipping to change at page 87, line 33 ¶		skipping to change at page 86, line 33 ¶
	"Provides a set of attack details.";		"Provides a set of attack details.";
	uses attack-detail;		uses attack-detail;
	container top-talker {		container top-talker {
	description		description
	"Lists the top attack sources.";		"Lists the top attack sources.";
	uses top-talker;		uses top-talker;
	}		}
	}		}
	}		}
	sx:augment-structure "/signal:dots-signal/signal:message-type/"		sx:augment-structure "/dots-signal:dots-signal/"
	+ "signal:mitigation-scope/signal:scope" {		+ "dots-signal:message-type/"
			+ "dots-signal:mitigation-scope/"
			+ "dots-signal:scope" {
	description		description
	"Extends mitigation scope with telemetry update data.";		"Extends mitigation scope with telemetry update data.";
	choice direction {		choice direction {
	description		description
	"Indicates the communication direction in which the		"Indicates the communication direction in which the
	data nodes can be included.";		data nodes can be included.";
	case server-to-client-only {		case server-to-client-only {
	description		description
	"These data nodes appear only in a mitigation message		"These data nodes appear only in a mitigation message
	sent from the server to the client.";		sent from the server to the client.";
	skipping to change at page 92, line 33 ¶		skipping to change at page 91, line 35 ¶
	type uint32;		type uint32;
	description		description
	"An identifier to uniquely demux telemetry data sent		"An identifier to uniquely demux telemetry data sent
	using the same message.";		using the same message.";
	}		}
	}		}
	}		}
	container target {		container target {
	description		description
	"Indicates the target.";		"Indicates the target.";
	uses ietf-data:target;		uses data-channel:target;
	leaf-list alias-name {		leaf-list alias-name {
	type string;		type string;
	description		description
	"An alias name that points to a resource.";		"An alias name that points to a resource.";
	}		}
	leaf-list mid-list {		leaf-list mid-list {
	type uint32;		type uint32;
	description		description
	"Reference a list of associated mitigation requests.";		"Reference a list of associated mitigation requests.";
	}		}
	skipping to change at page 93, line 14 ¶		skipping to change at page 92, line 15 ¶
	10.2. Vendor Attack Mapping Details YANG Module		10.2. Vendor Attack Mapping Details YANG Module
	<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang"		<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang"
	module ietf-dots-mapping {		module ietf-dots-mapping {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
	prefix dots-mapping;		prefix dots-mapping;
	import ietf-dots-data-channel {		import ietf-dots-data-channel {
	prefix ietf-data;		prefix data-channel;
	reference		reference
	"RFC 8783: Distributed Denial-of-Service Open Threat		"RFC 8783: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Data Channel Specification";		Signaling (DOTS) Data Channel Specification";
	}		}
	organization		organization
	"IETF DDoS Open Threat Signaling (DOTS) Working Group";		"IETF DDoS Open Threat Signaling (DOTS) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/dots/>		"WG Web: <https://datatracker.ietf.org/wg/dots/>
	WG List: <mailto:dots@ietf.org>		WG List: <mailto:dots@ietf.org>
	skipping to change at page 95, line 13 ¶		skipping to change at page 94, line 15 ¶
	description		description
	"Textual representation of attack description. Natural		"Textual representation of attack description. Natural
	Language Processing techniques (e.g., word embedding)		Language Processing techniques (e.g., word embedding)
	can possibly be used to map the attack description to		can possibly be used to map the attack description to
	an attack type.";		an attack type.";
	}		}
	}		}
	}		}
	}		}
	augment "/ietf-data:dots-data/ietf-data:dots-client" {		augment "/data-channel:dots-data/data-channel:dots-client" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Augments the data channel with a vendor attack		"Augments the data channel with a vendor attack
	mapping table of the DOTS client.";		mapping table of the DOTS client.";
	container vendor-mapping {		container vendor-mapping {
	description		description
	"Used by DOTS clients to share their vendor		"Used by DOTS clients to share their vendor
	attack mapping information with DOTS servers.";		attack mapping information with DOTS servers.";
	uses attack-mapping;		uses attack-mapping;
	}		}
	}		}
	augment "/ietf-data:dots-data/ietf-data:capabilities" {		augment "/data-channel:dots-data/data-channel:capabilities" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Augments the DOTS server capabilities with a		"Augments the DOTS server capabilities with a
	parameter to indicate whether they can share		parameter to indicate whether they can share
	attack mapping details.";		attack mapping details.";
	leaf vendor-mapping-enabled {		leaf vendor-mapping-enabled {
	type boolean;		type boolean;
	config false;		config false;
	description		description
	"Indicates that the server supports sharing		"Indicates that the server supports sharing
	attack vendor mapping details with DOTS clients.";		attack vendor mapping details with DOTS clients.";
	}		}
	}		}
	augment "/ietf-data:dots-data" {		augment "/data-channel:dots-data" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Augments the data channel with a vendor attack		"Augments the data channel with a vendor attack
	mapping table of the DOTS server.";		mapping table of the DOTS server.";
	container vendor-mapping {		container vendor-mapping {
	config false;		config false;
	description		description
	"Includes the list of vendor attack mapping details		"Includes the list of vendor attack mapping details
	that will be shared upon request with DOTS clients.";		that will be shared upon request with DOTS clients.";
	uses attack-mapping;		uses attack-mapping;
	skipping to change at page 102, line 22 ¶		skipping to change at page 101, line 22 ¶
	namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping		namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
	maintained by IANA: N		maintained by IANA: N
	prefix: dots-mapping		prefix: dots-mapping
	reference: RFC XXXX		reference: RFC XXXX
	13. Security Considerations		13. Security Considerations
	13.1. DOTS Signal Channel Telemetry		13.1. DOTS Signal Channel Telemetry
	The security considerations for the DOTS signal channel protocol are		The security considerations for the DOTS signal channel protocol are
	discussed in Section 12 of [I-D.boucadair-dots-rfc8782-bis]. The		discussed in Section 11 of [I-D.ietf-dots-rfc8782-bis]. The
	following discusses the security considerations that are specific to		following discusses the security considerations that are specific to
	the DOTS signal channel extension defined in this document.		the DOTS signal channel extension defined in this document.
	The DOTS telemetry information includes DOTS client network topology,		The DOTS telemetry information includes DOTS client network topology,
	DOTS client domain pipe capacity, normal traffic baseline and		DOTS client domain pipe capacity, normal traffic baseline and
	connections capacity, and threat and mitigation information. Such		connections capacity, and threat and mitigation information. Such
	information is sensitive; it MUST be protected at rest by the DOTS		information is sensitive; it MUST be protected at rest by the DOTS
	server domain to prevent data leakage.		server domain to prevent data leakage.
	DOTS clients are typically trusted devices by the DOTS client domain.		DOTS clients are typically trusted devices by the DOTS client domain.
	skipping to change at page 102, line 46 ¶		skipping to change at page 101, line 46 ¶
	held view that devices are untrusted, often referred to as the "zero-		held view that devices are untrusted, often referred to as the "zero-
	trust model". A compromised DOTS client can send fake DOTS telemetry		trust model". A compromised DOTS client can send fake DOTS telemetry
	data to a DOTS server to mislead the DOTS server. This attack can be		data to a DOTS server to mislead the DOTS server. This attack can be
	prevented by monitoring and auditing DOTS clients to detect		prevented by monitoring and auditing DOTS clients to detect
	misbehavior and to deter misuse, and by only authorizing the DOTS		misbehavior and to deter misuse, and by only authorizing the DOTS
	client to convey the DOTS telemetry for specific target resources		client to convey the DOTS telemetry for specific target resources
	(e.g., an application server is authorized to exchange DOTS telemetry		(e.g., an application server is authorized to exchange DOTS telemetry
	for its IP addresses but a DDoS mitigator can exchange DOTS telemetry		for its IP addresses but a DDoS mitigator can exchange DOTS telemetry
	for any target resource in the network). As a reminder, this is		for any target resource in the network). As a reminder, this is
	variation of dealing with compromised DOTS clients as discussed in		variation of dealing with compromised DOTS clients as discussed in
	Section 12 of [I-D.boucadair-dots-rfc8782-bis].		Section 11 of [I-D.ietf-dots-rfc8782-bis].
	DOTS servers must be capable of defending themselves against DoS		DOTS servers must be capable of defending themselves against DoS
	attacks from compromised DOTS clients. The following non-		attacks from compromised DOTS clients. The following non-
	comprehensive list of mitigation techniques can be used by a DOTS		comprehensive list of mitigation techniques can be used by a DOTS
	server to handle misbehaving DOTS clients:		server to handle misbehaving DOTS clients:
	o The probing rate (defined in Section 5.5 of		o The probing rate (defined in Section 4.5 of
	[I-D.boucadair-dots-rfc8782-bis]) can be used to limit the average		[I-D.ietf-dots-rfc8782-bis]) can be used to limit the average data
	data rate to the DOTS server.		rate to the DOTS server.
	o Rate-limiting DOTS telemetry, including those with new 'tmid'		o Rate-limiting DOTS telemetry, including those with new 'tmid'
	values, from the same DOTS client defends against DoS attacks that		values, from the same DOTS client defends against DoS attacks that
	would result in varying the 'tmid' to exhaust DOTS server		would result in varying the 'tmid' to exhaust DOTS server
	resources. Likewise, the DOTS server can enforce a quota and		resources. Likewise, the DOTS server can enforce a quota and
	time-limit on the number of active pre-or-ongoing-mitigation		time-limit on the number of active pre-or-ongoing-mitigation
	telemetry data (identified by 'tmid') from the DOTS client.		telemetry data (identified by 'tmid') from the DOTS client.
	Note also that telemetry notification interval may be used to rate-		Note also that telemetry notification interval may be used to rate-
	limit the pre-or-ongoing-mitigation telemetry notifications received		limit the pre-or-ongoing-mitigation telemetry notifications received
	skipping to change at page 103, line 38 ¶		skipping to change at page 102, line 38 ¶
	which can be created, modified, and deleted (i.e., config true, which		which can be created, modified, and deleted (i.e., config true, which
	is the default) are considered sensitive. Write operations to these		is the default) are considered sensitive. Write operations to these
	data nodes without proper protection can have a negative effect on		data nodes without proper protection can have a negative effect on
	network operations. Appropriate security measures are recommended to		network operations. Appropriate security measures are recommended to
	prevent illegitimate users from invoking DOTS data channel primitives		prevent illegitimate users from invoking DOTS data channel primitives
	as discussed in [RFC8783]. Nevertheless, an attacker who can access		as discussed in [RFC8783]. Nevertheless, an attacker who can access
	a DOTS client is technically capable of undertaking various attacks,		a DOTS client is technically capable of undertaking various attacks,
	such as:		such as:
	o Communicating invalid attack mapping details to the server		o Communicating invalid attack mapping details to the server
	('/ietf-data:dots-data/ietf-data:dots-client/dots-		('/data-channel:dots-data/data-channel:dots-client/dots-
	telemetry:vendor-mapping'), which will mislead the server when		telemetry:vendor-mapping'), which will mislead the server when
	correlating attack details.		correlating attack details.
	Some of the readable data nodes in the YANG module specified in		Some of the readable data nodes in the YANG module specified in
	Section 10.2 may be considered sensitive. It is thus important to		Section 10.2 may be considered sensitive. It is thus important to
	control read access to these data nodes. These are the data nodes		control read access to these data nodes. These are the data nodes
	and their sensitivity:		and their sensitivity:
	o '/ietf-data:dots-data/ietf-data:dots-client/dots-telemetry:vendor-		o '/data-channel:dots-data/data-channel:dots-client/dots-
	mapping' can be misused to infer the DDoS protection technology		telemetry:vendor-mapping' can be misused to infer the DDoS
	deployed in a DOTS client domain.		protection technology deployed in a DOTS client domain.
	o '/ietf-data:dots-data/dots-telemetry:vendor-mapping' can be used		o '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
	by a compromised DOTS client to leak the attack detection		used by a compromised DOTS client to leak the attack detection
	capabilities of the DOTS server. This is a variation of the		capabilities of the DOTS server. This is a variation of the
	compromised DOTS client attacks discussed in Section 13.1.		compromised DOTS client attacks discussed in Section 13.1.
	14. Contributors		14. Contributors
	The following individuals have contributed to this document:		The following individuals have contributed to this document:
	o Li Su, CMCC, Email: suli@chinamobile.com		o Li Su, CMCC, Email: suli@chinamobile.com
	o Pan Wei, Huawei, Email: william.panwei@huawei.com		o Pan Wei, Huawei, Email: william.panwei@huawei.com
	skipping to change at page 104, line 38 ¶		skipping to change at page 103, line 38 ¶
	Nainar for the opsdir review.		Nainar for the opsdir review.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[Enterprise-Numbers]		[Enterprise-Numbers]
	"Private Enterprise Numbers", May 2020,		"Private Enterprise Numbers", May 2020,
	<http://www.iana.org/assignments/enterprise-numbers.html>.		<http://www.iana.org/assignments/enterprise-numbers.html>.
	[I-D.boucadair-dots-rfc8782-bis]		[I-D.ietf-dots-rfc8782-bis]
	Boucadair, M., Ed., Shallow, J., and T. Reddy.K,		Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed
	"Distributed Denial-of-Service Open Threat Signaling		Denial-of-Service Open Threat Signaling (DOTS) Signal
	(DOTS) Signal Channel Specification",		Channel Specification", draft-ietf-dots-rfc8782-bis-01
	<https://tools.ietf.org/html/draft-boucadair-dots-rfc8782-		(work in progress), September 2020.
	bis-00>.
	[I-D.ietf-dots-signal-filter-control]		[I-D.ietf-dots-signal-filter-control]
	Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,		Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
	"Controlling Filtering Rules Using Distributed Denial-of-		"Controlling Filtering Rules Using Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel",		Service Open Threat Signaling (DOTS) Signal Channel",
	draft-ietf-dots-signal-filter-control-07 (work in		draft-ietf-dots-signal-filter-control-07 (work in
	progress), June 2020.		progress), June 2020.
	[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,
	skipping to change at page 106, line 14 ¶		skipping to change at page 105, line 14 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,		[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for		Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March		Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
	2018, <https://www.rfc-editor.org/info/rfc8345>.		2018, <https://www.rfc-editor.org/info/rfc8345>.
	[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
	Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
	DOI 10.17487/RFC8768, March 2020,
	<https://www.rfc-editor.org/info/rfc8768>.
	[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed		[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Data		Denial-of-Service Open Threat Signaling (DOTS) Data
	Channel Specification", RFC 8783, DOI 10.17487/RFC8783,		Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
	May 2020, <https://www.rfc-editor.org/info/rfc8783>.		May 2020, <https://www.rfc-editor.org/info/rfc8783>.
	[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data		[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data
	Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,		Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
	June 2020, <https://www.rfc-editor.org/info/rfc8791>.		June 2020, <https://www.rfc-editor.org/info/rfc8791>.
	16.2. Informative References		16.2. Informative References
	[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",		[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
	<https://www.iana.org/assignments/dots/dots.xhtml#dots-		<https://www.iana.org/assignments/dots/dots.xhtml#dots-
	signal-channel-conflict-cause-codes>.		signal-channel-conflict-cause-codes>.
	[I-D.bosh-core-new-block]
	Boucadair, M. and J. Shallow, "Constrained Application
	Protocol (CoAP) Block-Wise Transfer Options for Faster
	Transmission", draft-bosh-core-new-block-04 (work in
	progress), June 2020.
	[I-D.doron-dots-telemetry]		[I-D.doron-dots-telemetry]
	Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.		Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.
	Nishizuka, "Distributed Denial-of-Service Open Threat		Nishizuka, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry Specifications", draft-doron-		Signaling (DOTS) Telemetry Specifications", draft-doron-
	dots-telemetry-00 (work in progress), October 2016.		dots-telemetry-00 (work in progress), October 2016.
			[I-D.ietf-core-new-block]
			Boucadair, M. and J. Shallow, "Constrained Application
			Protocol (CoAP) Block-Wise Transfer Options for Faster
			Transmission", draft-ietf-core-new-block-01 (work in
			progress), September 2020.
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing		Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
	Deployment Considerations for Distributed-Denial-of-		Deployment Considerations for Distributed-Denial-of-
	Service Open Threat Signaling (DOTS)", draft-ietf-dots-		Service Open Threat Signaling (DOTS)", draft-ietf-dots-
	multihoming-04 (work in progress), May 2020.		multihoming-04 (work in progress), May 2020.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	L., and K. Nishizuka, "Use cases for DDoS Open Threat		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Signaling", draft-ietf-dots-use-cases-25 (work in		Signaling", draft-ietf-dots-use-cases-25 (work in
End of changes. 56 change blocks.
	139 lines changed or deleted		133 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/