< draft-ietf-dots-telemetry-18.txt		draft-ietf-dots-telemetry-19.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: 16 June 2022 Akamai		Expires: 8 July 2022 Akamai
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	13 December 2021		4 January 2022
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-18		draft-ietf-dots-telemetry-19
	Abstract		Abstract
	This document aims to enrich the DOTS signal channel protocol with		This document aims to enrich the DOTS signal channel protocol with
	various telemetry attributes, allowing for optimal Distributed		various telemetry attributes, allowing for optimal Distributed
	Denial-of-Service (DDoS) attack mitigation. It specifies the normal		Denial-of-Service (DDoS) attack mitigation. It specifies the normal
	traffic baseline and attack traffic telemetry attributes a DOTS		traffic baseline and attack traffic telemetry attributes a DOTS
	client can convey to its DOTS server in the mitigation request, the		client can convey to its DOTS server in the mitigation request, the
	mitigation status telemetry attributes a DOTS server can communicate		mitigation status telemetry attributes a DOTS server can communicate
	to a DOTS client, and the mitigation efficacy telemetry attributes a		to a DOTS client, and the mitigation efficacy telemetry attributes a
	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 16 June 2022.		This Internet-Draft will expire on 8 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102		11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
	12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105		12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105
	12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 108		12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 108
	12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108		12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 109		13. Security Considerations . . . . . . . . . . . . . . . . . . . 109
	13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 109		13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 109
	13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 110		13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 110
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 111		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 112
	16.1. Normative References . . . . . . . . . . . . . . . . . . 111		16.1. Normative References . . . . . . . . . . . . . . . . . . 112
	16.2. Informative References . . . . . . . . . . . . . . . . . 113		16.2. Informative References . . . . . . . . . . . . . . . . . 113
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
	1. Introduction		1. Introduction
	IT organizations and service providers are facing Distributed Denial		IT organizations and service providers are facing Distributed Denial
	of Service (DDoS) attacks that fall into two broad categories:		of Service (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
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 21 ¶
	normal behavior and target the baseline as the level of normality		normal behavior and target the baseline as the level of normality
	they need to achieve. Fed with this information, the overall		they need to achieve. Fed with this information, the overall
	mitigation performances is expected to be improved in terms of time		mitigation performances is expected to be improved in terms of time
	to mitigate, accuracy, and false-negative and false-positive rates.		to mitigate, accuracy, and false-negative and false-positive rates.
	Mitigation of attacks without having certain knowledge of normal		Mitigation of attacks without having certain knowledge of normal
	traffic can be inaccurate at best. This is especially true for		traffic can be inaccurate at best. This is especially true for
	recursive signaling (see Section 3.2.3 of [RFC8811]). Given that		recursive signaling (see Section 3.2.3 of [RFC8811]). Given that
	DOTS clients can be integrated in a highly diverse set of scenarios		DOTS clients can be integrated in a highly diverse set of scenarios
	and use cases, this emphasizes the need for knowledge of each DOTS		and use cases, this emphasizes the need for knowledge of each DOTS
	client domain behavior especially that common global thresholds for		client domain behavior, especially given that common global
	attack detection practically cannot be realized. Each DOTS client		thresholds for attack detection practically cannot be realized. Each
	domain can have its own levels of traffic and normal behavior.		DOTS client domain can have its own levels of traffic and normal
	Without facilitating normal baseline signaling, it may be very		behavior. Without facilitating normal baseline signaling, it may be
	difficult for DOTS servers in some cases to detect and mitigate the		very difficult for DOTS servers in some cases to detect and mitigate
	attacks accurately:		the attacks accurately:
	It is important to emphasize that it is practically impossible for		It is important to emphasize that it is practically impossible for
	the DOTS server's mitigators to calculate the normal baseline in		the DOTS server's mitigators to calculate the normal baseline in
	cases where they do not have any knowledge of the traffic		cases where they do not have any knowledge of the traffic
	beforehand.		beforehand.
	In addition, baseline learning requires a period of time that		In addition, baseline learning requires a period of time that
	cannot be afforded during active attack.		cannot be afforded during active attack.
	Of course, this information can provided using out-of-band mechanisms		Of course, this information can provided using out-of-band mechanisms
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 45 ¶
	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 4.4.2 of [RFC9132] to control the		recommendation detailed in Section 4.4.2 of [RFC9132] to control the
	size of a response when the data to be returned does not fit within a		size of a response when the data to be returned does not fit within a
	single datagram.		single datagram.
	DOTS clients can also use CoAP Block1 Option in a PUT request		DOTS clients can also use CoAP Block1 Option in a PUT request
	(Section 2.5 of [RFC7959]) to initiate large transfers, but these		(Section 2.5 of [RFC7959]) to initiate large transfers, but these
	Block1 transfers is likely to fail if the inbound "pipe" is running		Block1 transfers are likely to fail if the inbound "pipe" is running
	full because the transfer requires a message from the server for each		full because the transfer requires a message from the server for each
	block, which would likely be lost in the incoming flood.		block, which would likely be lost in the incoming flood.
	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.
	Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and		Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and
	Block2 Options, but enable robust transmissions of big blocks of data		Block2 Options, but enable robust transmissions of big blocks of data
	with less packet interchanges using NON messages, are defined in		with less packet interchanges using NON messages, are defined in
	[I-D.ietf-core-new-block]. DOTS implementations can consider the use		[I-D.ietf-core-new-block]. DOTS implementations can consider the use
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 47 ¶
	| | ...		| | ...
	| +--:(pipe)		| +--:(pipe)
	| | ...		| | ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry)		+--:(telemetry)
	...		...
	Figure 1: New DOTS Message Types (YANG Tree Structure)		Figure 1: New DOTS Message Types (YANG Tree Structure)
	DOTS implementations MUST support the Observe Option for 'tm'		DOTS implementations MUST support the Observe Option [RFC7641] for
	(Section 7).		'tm' (Section 7).
	6. DOTS Telemetry Setup Configuration		6. DOTS Telemetry Setup Configuration
	In reference to Figure 1, a DOTS telemetry setup message MUST include		In reference to Figure 1, a DOTS telemetry setup message MUST include
	only telemetry-related configuration parameters (Section 6.1) or		only telemetry-related configuration parameters (Section 6.1) or
	information about DOTS client domain pipe capacity (Section 6.2) or		information about DOTS client domain pipe capacity (Section 6.2) or
	telemetry traffic baseline (Section 6.3). As such, requests that		telemetry traffic baseline (Section 6.3). As such, requests that
	include a mix of telemetry configuration, pipe capacity, and traffic		include a mix of telemetry configuration, pipe capacity, and traffic
	baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).		baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	Section 6.4.		Section 6.4.
	A DOTS server may detect conflicts when processing requests related		A DOTS server may detect conflicts when processing requests related
	to DOTS client domain pipe capacity or telemetry traffic baseline		to DOTS client domain pipe capacity or telemetry traffic baseline
	with requests from other DOTS clients of the same DOTS client domain.		with requests from other DOTS clients of the same DOTS client domain.
	More details are included in Section 6.5.		More details are included in Section 6.5.
	Telemetry setup configuration is bound to a DOTS client domain. DOTS		Telemetry setup configuration is bound to a DOTS client domain. DOTS
	servers MUST NOT expect DOTS clients to send regular requests to		servers MUST NOT expect DOTS clients to send regular requests to
	refresh the telemetry setup configuration. Any available telemetry		refresh the telemetry setup configuration. Any available telemetry
	setup configuration has a validity timeout of the DOTS association		setup configuration is valid till the DOTS server ceases to service a
	with a DOTS client domain. DOTS servers MUST NOT reset 'tsid'		DOTS client domain. DOTS servers MUST NOT reset 'tsid' because a
	because a session failed with a DOTS client. DOTS clients update		session failed with a DOTS client. DOTS clients update their
	their telemetry setup configuration upon change of a parameter that		telemetry setup configuration upon change of a parameter that may
	may impact attack mitigation.		impact attack mitigation.
	DOTS telemetry setup configuration request and response messages are		DOTS telemetry setup configuration request and response messages are
	marked as Confirmable messages (Section 2.1 of [RFC7252]).		marked as Confirmable messages (Section 2.1 of [RFC7252]).
	6.1. Telemetry Configuration		6.1. Telemetry Configuration
	DOTS telemetry uses several percentile values to provide a picture of		DOTS telemetry uses several percentile values to provide a picture of
	a traffic distribution overall, as opposed to just a single snapshot		a traffic distribution overall, as opposed to just a single snapshot
	of observed traffic at a single point in time. Modeling raw traffic		of observed traffic at a single point in time. Modeling raw traffic
	flow data as a distribution and describing that distribution entails		flow data as a distribution and describing that distribution entails
	skipping to change at page 21, line 32 ¶		skipping to change at page 21, line 32 ¶
	client can send the request depicted in Figure 5 to inform the server		client can send the request depicted in Figure 5 to inform the server
	that it is interested in receiving only high-percentiles. This		that it is interested in receiving only high-percentiles. This
	assumes that the client will only use that percentile type when		assumes that the client will only use that percentile type when
	sharing telemetry data with the server.		sharing telemetry data with the server.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=569"		Uri-Path: "tsid=124"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"low-percentile": "0.00",		"low-percentile": "0.00",
	"mid-percentile": "0.00",		"mid-percentile": "0.00",
	"high-percentile": "95.00"		"high-percentile": "95.00"
	skipping to change at page 22, line 8 ¶		skipping to change at page 22, line 8 ¶
	}		}
	]		]
	}		}
	}		}
	Figure 5: PUT to Disable Low- and Mid-Percentiles		Figure 5: PUT to Disable Low- and Mid-Percentiles
	DOTS clients can also configure the unit class(es) to be used for		DOTS clients can also configure the unit class(es) to be used for
	traffic-related telemetry data among the following supported unit		traffic-related telemetry data among the following supported unit
	classes: packets per second, bits per second, and bytes per second.		classes: packets per second, bits per second, and bytes per second.
			Supplying both bits per second and bytes per second unit-classes is
			allowed for a given telemetry data. However, receipt of conflicting
			values is treated as invalid parameters and rejected with 4.00 (Bad
			Request).
	DOTS clients that are interested to receive pre or ongoing mitigation		DOTS clients that are interested to receive pre or ongoing mitigation
	telemetry (pre-or-ongoing-mitigation) information from a DOTS server		telemetry (pre-or-ongoing-mitigation) information from a DOTS server
	(Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If		(Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If
	'server-originated-telemetry' is not present in a PUT request, this		'server-originated-telemetry' is not present in a PUT request, this
	is equivalent to receiving a request with 'server-originated-		is equivalent to receiving a request with 'server-originated-
	telemetry' set to 'false'. An example of a request to enable pre-or-		telemetry' set to 'false'. An example of a request to enable pre-or-
	ongoing-mitigation telemetry from DOTS servers is shown in Figure 6.		ongoing-mitigation telemetry from DOTS servers is shown in Figure 6.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=569"		Uri-Path: "tsid=125"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"server-originated-telemetry": true		"server-originated-telemetry": true
	}		}
	}		}
	skipping to change at page 25, line 35 ¶		skipping to change at page 25, line 35 ¶
	`-. Domain ,-' link1 `-. ,-'		`-. Domain ,-' link1 `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 10: Single Homed DOTS Client Domain		Figure 10: Single Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=457"		Uri-Path: "tsid=126"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": "500",		"capacity": "500",
	skipping to change at page 26, line 26 ¶		skipping to change at page 26, line 26 ¶
	( DOTS Client ) ( ISP#C )		( DOTS Client ) ( ISP#C )
	`-. Domain ,-'====== `-. ,-'		`-. Domain ,-'====== `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 12: DOTS Client Domain with Two Interconnection Links		Figure 12: DOTS Client Domain with Two Interconnection Links
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
	Uri-Path: "tsid=896"		Uri-Path: "tsid=896"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "aggregate",		"link-id": "aggregate",
	skipping to change at page 27, line 7 ¶		skipping to change at page 27, line 7 ¶
	Figure 13: Example of a PUT Request to Convey Pipe Information		Figure 13: Example of a PUT Request to Convey Pipe Information
	(Aggregated Link)		(Aggregated Link)
	Now consider that the DOTS client domain was upgraded to connect to		Now consider that the DOTS client domain was upgraded to connect to
	an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can		an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can
	inform a third-party DOTS server (that is, not hosted with ISP#A and		inform a third-party DOTS server (that is, not hosted with ISP#A and
	ISP#B domains) about this update by sending the PUT request depicted		ISP#B domains) about this update by sending the PUT request depicted
	in Figure 15. This request also includes information related to		in Figure 15. This request also includes information related to
	"link1" even if that link is not upgraded. Upon receipt of this		"link1" even if that link is not upgraded. Upon receipt of this
	request, the DOTS server removes the request with 'tsid=457' and		request, the DOTS server removes the request with 'tsid=126' and
	updates its configuration base to maintain two links (link#1 and		updates its configuration base to maintain two links (link#1 and
	link#2).		link#2).
	,--,--,--.		,--,--,--.
	,-' `-.		,-' `-.
	( ISP#B )		( ISP#B )
	`-. ,-'		`-. ,-'
	`--'--'--'		`--'--'--'
	||		||
	|| link2		|| link2
	skipping to change at page 28, line 10 ¶		skipping to change at page 28, line 10 ¶
	`-. Domain ,-' link1 `-. ,-'		`-. Domain ,-' link1 `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 14: Multi-Homed DOTS Client Domain		Figure 14: Multi-Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=458"		Uri-Path: "tsid=127"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": "500",		"capacity": "500",
	skipping to change at page 29, line 25 ¶		skipping to change at page 29, line 25 ¶
	`-. Domain ,-'		`-. Domain ,-'
	`--'--'--'		`--'--'--'
	Figure 16: Multi-Homed DOTS Client Domain		Figure 16: Multi-Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=459"		Uri-Path: "tsid=128"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": "0",		"capacity": "0",
	skipping to change at page 35, line 10 ¶		skipping to change at page 35, line 10 ¶
	domain as a whole.		domain as a whole.
	An example of a PUT request to convey the baseline information is		An example of a PUT request to convey the baseline information is
	shown in Figure 19.		shown in Figure 19.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=126"		Uri-Path: "tsid=129"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"baseline": [		"baseline": [
	{		{
	"id": 1,		"id": 1,
	"target-prefix": [		"target-prefix": [
	skipping to change at page 36, line 10 ¶		skipping to change at page 36, line 10 ¶
	Figure 19: PUT to Conveying the DOTS Traffic Baseline		Figure 19: PUT to Conveying the DOTS Traffic Baseline
	The DOTS client may share protocol specific baseline information		The DOTS client may share protocol specific baseline information
	(e.g., TCP and UDP) as shown in Figure 19.		(e.g., TCP and UDP) as shown in Figure 19.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=128"		Uri-Path: "tsid=130"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"baseline": [		"baseline": [
	{		{
	"id": 1,		"id": 1,
	"target-prefix": [		"target-prefix": [
	skipping to change at page 48, line 26 ¶		skipping to change at page 48, line 26 ¶
	This attribute (depicted in Figure 29) is used to signal a set of		This attribute (depicted in Figure 29) is used to signal a set of
	details characterizing an attack. The following subattributes		details characterizing an attack. The following subattributes
	describing the ongoing attack can be signalled as attack details:		describing the ongoing attack can be signalled as attack details:
	vendor-id: Vendor ID is a security vendor's Enterprise Number as		vendor-id: Vendor ID is a security vendor's Enterprise Number as
	registered with IANA [Enterprise-Numbers]. It is a four-byte		registered with IANA [Enterprise-Numbers]. It is a four-byte
	integer value.		integer value.
	attack-id: Unique identifier assigned for the attack by a vendor.		attack-id: Unique identifier assigned for the attack by a vendor.
			This parameter MUST be present independently whether 'attack-
			description' is included or not.
	attack-description: Textual representation of the attack		attack-description: Textual representation of the attack
	description. Natural Language Processing techniques (e.g., word		description. Natural Language Processing techniques (e.g., word
	embedding) might provide some utility in mapping the attack		embedding) might provide some utility in mapping the attack
	description to an attack type. Textual representation of attack		description to an attack type. Textual representation of attack
	solves two problems: (a) avoids the need to create mapping tables		solves two problems: (a) avoids the need to create mapping tables
	manually between vendors and (b) avoids the need to standardize		manually between vendors and (b) avoids the need to standardize
	attack types which keep evolving.		attack types which keep evolving.
	attack-severity: Attack severity level. This attribute takes one of		attack-severity: Attack severity level. This attribute takes one of
	skipping to change at page 52, line 35 ¶		skipping to change at page 52, line 35 ¶
	+--ro attack-description string		+--ro attack-description string
	Figure 30: Vendor Attack Mapping Tree Structure		Figure 30: Vendor Attack Mapping Tree Structure
	A DOTS client sends a GET request to retrieve the capabilities		A DOTS client sends a GET request to retrieve the capabilities
	supported by a DOTS server as per Section 7.1 of [RFC8783]. This		supported by a DOTS server as per Section 7.1 of [RFC8783]. This
	request is meant to assess whether the capability of sharing vendor		request is meant to assess whether the capability of sharing vendor
	attack mapping details is supported by the server (i.e., check the		attack mapping details is supported by the server (i.e., check the
	value of 'vendor-mapping-enabled').		value of 'vendor-mapping-enabled').
	If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send		If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send
	a GET request to retrieve the DOTS server's vendor attack mapping		a GET request to retrieve the DOTS server's vendor attack mapping
	details. An example of such a GET request is shown in Figure 31.		details. An example of such a GET request is shown in Figure 31.
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/ietf-dots-mapping:vendor-mapping HTTP/1.1		/ietf-dots-mapping:vendor-mapping HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS		Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS
	Server		Server
	skipping to change at page 55, line 7 ¶		skipping to change at page 55, line 7 ¶
	If the request is received via a server-domain DOTS gateway, but the		If the request is received via a server-domain DOTS gateway, but the
	DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'		DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
	is expected to be supplied, the DOTS server MUST reply with "403		is expected to be supplied, the DOTS server MUST reply with "403
	Forbidden" status-line and the error-tag "access-denied". Upon		Forbidden" status-line and the error-tag "access-denied". Upon
	receipt of this message, the DOTS client MUST register (Section 5.1		receipt of this message, the DOTS client MUST register (Section 5.1
	of [RFC8783]).		of [RFC8783]).
	The DOTS client uses the PUT request to modify its vendor attack		The DOTS client uses the PUT request to modify its vendor attack
	mapping details maintained by the DOTS server (e.g., add a new		mapping details maintained by the DOTS server (e.g., add a new
	mapping).		mapping entry, update an existing mapping).
	A DOTS client uses a GET request to retrieve its vendor attack		A DOTS client uses a GET request to retrieve its vendor attack
	mapping details as maintained by the DOTS server (Figure 35).		mapping details as maintained by the DOTS server (Figure 35).
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/dots-client=dz6pHjaADkaFTbjr0JGBpw\		/dots-client=dz6pHjaADkaFTbjr0JGBpw\
	/ietf-dots-mapping:vendor-mapping?\		/ietf-dots-mapping:vendor-mapping?\
	content=all HTTP/1.1		content=all HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	skipping to change at page 64, line 47 ¶		skipping to change at page 64, line 47 ¶
	| ...		| ...
	+-- request-ps-c		+-- request-ps-c
	| ...		| ...
	+-- partial-request-c		+-- partial-request-c
	...		...
	Figure 44: Telemetry Efficacy Update Tree Structure		Figure 44: Telemetry Efficacy Update Tree Structure
	In order to signal telemetry data in a mitigation efficacy update, it		In order to signal telemetry data in a mitigation efficacy update, it
	is RECOMMENDED that the DOTS client has already established a DOTS		is RECOMMENDED that the DOTS client has already established a DOTS
	telemetry setup session with the server in 'idle' time.		telemetry setup session with the server in 'idle' time. Such a
			session is primary meant to assess whether the peer DOTS server
			supports telemetry extensions and, thus, prevent message processing
			failure (Section 3.1 of [RFC9132]).
	An example of an efficacy update with telemetry attributes is		An example of an efficacy update with telemetry attributes is
	depicted in Figure 45.		depicted in Figure 45.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "mid=123"		Uri-Path: "mid=123"
	skipping to change at page 66, line 15 ¶		skipping to change at page 66, 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 these countermeasures MAY also be included. The		attacks detected by these countermeasures 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"
	[RFC9132] with telemetry data as depicted in the following tree		[RFC9132] with telemetry data as depicted in Figure 46.
	structure:
	augment-structure /dots-signal:dots-signal/dots-signal:message-type		augment-structure /dots-signal:dots-signal/dots-signal:message-type
	/dots-signal:mitigation-scope/dots-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
	skipping to change at page 67, line 48 ¶		skipping to change at page 68, line 5 ¶
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- embryonic-c		+-- embryonic-c
	| ...		| ...
	+-- connection-ps-c		+-- connection-ps-c
	| ...		| ...
	+-- request-ps-c		+-- request-ps-c
	| ...		| ...
	+-- partial-request-c		+-- partial-request-c
	...		...
	Figure 46 shows an example of an asynchronous notification of attack		Figure 46: DOTS Servers to Clients Mitigation Status Telemetry
			Tree Structure
			Figure 47 shows an example of an asynchronous notification of attack
	mitigation status from the DOTS server. This notification signals		mitigation status from the DOTS server. This notification signals
	both the mid-percentile value of processed attack traffic and the		both the mid-percentile value of processed attack traffic and the
	peak count of unique sources involved in the attack.		peak count of unique sources involved in the attack.
	{		{
	"ietf-dots-signal-channel:mitigation-scope": {		"ietf-dots-signal-channel:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mid": 12332,		"mid": 12332,
	"mitigation-start": "1507818434",		"mitigation-start": "1507818434",
	skipping to change at page 68, line 41 ¶		skipping to change at page 68, line 49 ¶
	"source-count": {		"source-count": {
	"peak-g": "12683"		"peak-g": "12683"
	}		}
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 46: Response Body of a Mitigation Status With Telemetry		Figure 47: Response Body of a Mitigation Status With Telemetry
	Attributes		Attributes
	DOTS clients can filter out the asynchronous notifications from the		DOTS clients can filter out the asynchronous notifications from the
	DOTS server by indicating one or more Uri-Query options in its GET		DOTS server by indicating one or more Uri-Query options in its GET
	request. A Uri-Query option can include the following parameters:		request. A Uri-Query option can include the following parameters:
	'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',		'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
	'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The		'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The
	considerations discussed in Section 7.3 MUST be followed to include		considerations discussed in Section 7.3 MUST be followed to include
	multiple query values, ranges ('target-port', 'target-protocol'), and		multiple query values, ranges ('target-port', 'target-protocol'), and
	wildcard names ('target-fqdn', 'target-uri').		wildcard names ('target-fqdn', 'target-uri').
	An example of request to subscribe to asynchronous notifications		An example of request to subscribe to asynchronous notifications
	bound to the "http1" alias is shown in Figure 47.		bound to the "http1" alias is shown in Figure 48.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "mid=12332"		Uri-Path: "mid=12332"
	Uri-Query: "target-alias=https1"		Uri-Query: "target-alias=https1"
	Observe: 0		Observe: 0
	Figure 47: GET Request to Receive Asynchronous Notifications		Figure 48: GET Request to Receive Asynchronous Notifications
	Filtered using Uri- Query		Filtered 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. In such a		observe entry if this query overlaps with an existing one. In such a
	case, the DOTS server replies with 4.09 (Conflict).		case, the DOTS server replies with 4.09 (Conflict).
	9. Error Handling		9. Error Handling
	skipping to change at page 104, line 18 ¶		skipping to change at page 104, line 24 ¶
	| partial-request-c | container |TBA45 | 5 map | Object |		| partial-request-c | container |TBA45 | 5 map | Object |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection-protocol | list |TBA46 | 4 array | Array |		| connection-protocol | list |TBA46 | 4 array | Array |
	| baseline | list |TBA49 | 4 array | Array |		| baseline | list |TBA49 | 4 array | Array |
	| current-config | container |TBA50 | 5 map | Object |		| current-config | container |TBA50 | 5 map | Object |
	| max-config-values | container |TBA51 | 5 map | Object |		| max-config-values | container |TBA51 | 5 map | Object |
	| min-config-values | container |TBA52 | 5 map | Object |		| min-config-values | container |TBA52 | 5 map | Object |
	|supported-unit-classes| container |TBA53 | 5 map | Object |		|supported-unit-classes| container |TBA53 | 5 map | Object |
	| server-originated- | boolean |TBA54 | 7 bits 20 | False |		| server-originated- | boolean |TBA54 | 7 bits 20 | False |
	| telemetry | | | 7 bits 21 | True |		| telemetry | | | 7 bits 21 | True |
	| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |		| telemetry-notify- | uint16 |TBA55 | 0 unsigned | Number |
	| interval | | | | |		| interval | | | | |
	| tmid | uint32 |TBA56 | 0 unsigned | Number |		| tmid | uint32 |TBA56 | 0 unsigned | Number |
	| measurement-interval | enumeration |TBA57 | 0 unsigned | String |		| measurement-interval | enumeration |TBA57 | 0 unsigned | String |
	| measurement-sample | enumeration |TBA58 | 0 unsigned | String |		| measurement-sample | enumeration |TBA58 | 0 unsigned | String |
	| talker | list |TBA59 | 4 array | Array |		| talker | list |TBA59 | 4 array | Array |
	| source-prefix | inet: |TBA60 | 3 text string | String |		| source-prefix | inet: |TBA60 | 3 text string | String |
	| | ip-prefix | | | |		| | ip-prefix | | | |
	| mid-list | leaf-list |TBA61 | 4 array | Array |		| mid-list | leaf-list |TBA61 | 4 array | Array |
	| | uint32 | | 0 unsigned | Number |		| | uint32 | | 0 unsigned | Number |
	| source-port-range | list |TBA62 | 4 array | Array |		| source-port-range | list |TBA62 | 4 array | Array |
	skipping to change at page 112, line 50 ¶		skipping to change at page 113, line 27 ¶
	[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>.
	[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., Björklund, M., and K. Watsen, "YANG Data		[RFC8791] Bierman, A., Bjorklund, 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>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,		[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
	"Distributed Denial-of-Service Open Threat Signaling		"Distributed Denial-of-Service Open Threat Signaling
End of changes. 31 change blocks.
	41 lines changed or deleted		52 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/