< draft-ietf-dots-telemetry-13.txt		draft-ietf-dots-telemetry-14.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: April 11, 2021 McAfee		Expires: May 19, 2021 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	October 8, 2020		November 15, 2020
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-13		draft-ietf-dots-telemetry-14
	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 April 11, 2021.		This Internet-Draft will expire on May 19, 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 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	learned during active attacks because attack conditions do not		learned during active attacks because attack conditions do not
	characterize the protected entities' normal behavior.		characterize the protected entities' normal behavior.
	If the DOTS client has calculated the normal baseline of its		If the DOTS client has calculated the normal baseline of its
	protected entities, signaling such information to the DOTS server		protected entities, signaling such information to the DOTS server
	along with the attack traffic levels is significantly valuable. The		along with the attack traffic levels is significantly valuable. The
	DOTS server benefits from this telemetry by tuning its mitigation		DOTS server benefits from this telemetry by tuning its mitigation
	resources with the DOTS client's normal baseline. The DOTS server		resources with the DOTS client's normal baseline. The DOTS server
	mitigators use the baseline to familiarize themselves with the attack		mitigators use the baseline to familiarize themselves with the attack
	victim's normal behavior and target the baseline as the level of		victim's normal behavior and target the baseline as the level of
	normality they need to achieve. Fed with this inforamtion, the		normality they need to achieve. Fed with this information, the
	overall mitigation performances is expected to be improved in terms		overall mitigation performances is expected to be improved in terms
	of time to mitigate, accuracy, false-negative, and false-positive.		of time to mitigate, accuracy, false-negative, and false-positive.
	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 in [I-D.ietf-dots-use-cases]).		recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]).
	In addition, the highly diverse types of use cases where DOTS clients		In addition, the highly diverse types of use cases where DOTS clients
	are integrated also emphasize the need for knowledge of each DOTS		are integrated also emphasize the need for knowledge of each DOTS
	client domain behavior. Consequently, common global thresholds for		client domain behavior. Consequently, common global thresholds for
	attack detection practically cannot be realized. Each DOTS client		attack detection practically cannot be realized. Each DOTS client
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 22 ¶
	[I-D.ietf-dots-rfc8782-bis] to control the size of a response when		[I-D.ietf-dots-rfc8782-bis] to control the size of a response 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.
	Quick-Block1 and Quick-Block2 Options that are similar to the CoAP		Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and
	Block1 and Block2 Options, but enable faster transmissions of big		Block2 Options, but enable faster transmissions of big blocks of data
	blocks of data with less packet interchanges, are defined in		with less packet interchanges, 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
	of Quick-Block1 and Quick-Block2 Options.		of Q-Block1 and Q-Block2 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
	upstream network to the DOTS client domain will be signaled via the		upstream network to the DOTS client domain will be signaled via the
	skipping to change at page 47, line 27 ¶		skipping to change at page 47, line 27 ¶
	vendor identifier that is different to the one it uses to transmit		vendor identifier that is different to the one it uses to transmit
	telemetry data. Furthermore, it is possible that the DOTS client and		telemetry data. Furthermore, it is possible that the DOTS client and
	DOTS server are provided by the same vendor, but the vendor mapping		DOTS server are provided by the same vendor, but the vendor mapping
	tables are at different revisions. The DOTS client SHOULD transmit		tables are at different revisions. The DOTS client SHOULD transmit
	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 the
	module is shown in Figure 30.		"ietf-dots-mapping" module is shown in Figure 30.
	module: ietf-dots-mapping		module: ietf-dots-mapping
	augment /data-channel:dots-data/data-channel: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
	skipping to change at page 97, line 41 ¶		skipping to change at page 97, line 41 ¶
	| telemetry-setup | container |TBA80 | 5 map | Object |		| telemetry-setup | container |TBA80 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-traffic | list |TBA81 | 4 array | Array |		| total-traffic | list |TBA81 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack-traffic | list |TBA82 | 4 array | Array |		| total-attack-traffic | list |TBA82 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA83 | 5 map | Object |		| connection | container |TBA83 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-detail | list |TBA84 | 4 array | Array |		| attack-detail | list |TBA84 | 4 array | Array |
			| ietf-dots-telemetry: | | | | |
			| telemetry | container |TBA85 | 5 map | Object |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	12. IANA Considerations		12. IANA Considerations
	12.1. DOTS Signal Channel CBOR Key Values		12.1. DOTS Signal Channel CBOR Key Values
	This specification registers the DOTS telemetry attributes in the		This specification registers the DOTS telemetry attributes in the
	IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].		IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
	The DOTS telemetry attributes defined in this specification are		The DOTS telemetry attributes defined in this specification are
	skipping to change at page 100, line 20 ¶		skipping to change at page 100, line 23 ¶
	| telemetry-setup | | | | |		| telemetry-setup | | | | |
	| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |
	| total-traffic | | | | |		| total-traffic | | | | |
	| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
	| total-attack-traffic | | | | |		| total-attack-traffic | | | | |
	| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | | | | |		| connection | | | | |
	| ietf-dots-telemetry: | TBA84 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA84 | 4 | IESG | [RFCXXXX] |
	| attack-detail | | | | |		| attack-detail | | | | |
			| ietf-dots-telemetry: | TBA85 | 5 | IESG | [RFCXXXX] |
			| telemetry | | | | |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	12.2. DOTS Signal Channel Conflict Cause Codes		12.2. DOTS Signal Channel Conflict Cause Codes
	This specification requests IANA to assign a new code from the "DOTS		This specification requests IANA to assign a new code from the "DOTS
	Signal Channel Conflict Cause Codes" registry [Cause].		Signal Channel Conflict Cause Codes" registry [Cause].
	+------+-------------------+------------------------+-------------+		+------+-------------------+------------------------+-------------+
	| Code | Label | Description | Reference |		| Code | Label | Description | Reference |
	+======+===================+========================+=============+		+======+===================+========================+=============+
	skipping to change at page 105, line 38 ¶		skipping to change at page 105, line 46 ¶
	[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]		[I-D.ietf-core-new-block]
	Boucadair, M. and J. Shallow, "Constrained Application		Boucadair, M. and J. Shallow, "Constrained Application
	Protocol (CoAP) Block-Wise Transfer Options for Faster		Protocol (CoAP) Block-Wise Transfer Options for Faster
	Transmission", draft-ietf-core-new-block-01 (work in		Transmission", draft-ietf-core-new-block-02 (work in
	progress), September 2020.		progress), October 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
End of changes. 11 change blocks.
	13 lines changed or deleted		17 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/