draft-ietf-dots-signal-call-home-01.txt		draft-ietf-dots-signal-call-home-02.txt
	DOTS T. Reddy		DOTS T. Reddy
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair		Intended status: Standards Track M. Boucadair
	Expires: October 28, 2019 Orange		Expires: December 2, 2019 Orange
	J. Shallow		J. Shallow
	April 26, 2019		May 31, 2019
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal		Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Call Home		Channel Call Home
	draft-ietf-dots-signal-call-home-01		draft-ietf-dots-signal-call-home-02
	Abstract		Abstract
	This document specifies the DOTS signal channel Call Home service,		This document specifies the DOTS signal channel Call Home service,
	which enables a DOTS server to initiate a secure connection to a DOTS		which enables a DOTS server to initiate a secure connection to a DOTS
	client, and to receive the attack traffic information from the DOTS		client, and to receive the attack traffic information from the DOTS
	client. The DOTS server in turn uses the attack traffic information		client. The DOTS server in turn uses the attack traffic information
	to identify the compromised devices launching the outgoing DDoS		to identify the compromised devices launching the outgoing DDoS
	attack and takes appropriate mitigation action(s).		attack and takes appropriate mitigation action(s).
	The Call Home service is not specific to the home networks; the		The DOTS Call Home service is not specific to the home networks; the
	solution targets any deployment which requires to block DDoS attack		solution targets any deployment which requires to block DDoS attack
	traffic closer to the source(s) of a DDoS attack.		traffic closer to the source(s) of a DDoS attack.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 28, 2019.		This Internet-Draft will expire on December 2, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 21 ¶		skipping to change at page 2, line 21 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4		1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5		1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
	2. Notational Conventions and Terminology . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7		3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7
	3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 8		3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8
	3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 8		3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9
	3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 12		3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14
	4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 16		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 16		4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17
	4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 16		4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17
	4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 17		4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		9.2. Informative References . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	1.1. The Problem		1.1. The Problem
	The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is		The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is
	used to carry information about a network resource or a network (or a		used to carry information about a network resource or a network (or a
	part thereof) that is under a Distributed Denial of Service (DDoS)		part thereof) that is under a Distributed Denial of Service (DDoS)
	attack. Such information is sent by a DOTS client to one or multiple		attack. Such information is sent by a DOTS client to one or multiple
	DOTS servers so that appropriate mitigation actions are undertaken on		DOTS servers so that appropriate mitigation actions are undertaken on
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	Internet of Things (IoT) devices are becoming more and more prevalent		Internet of Things (IoT) devices are becoming more and more prevalent
	in home networks, and with compute and memory becoming cheaper and		in home networks, and with compute and memory becoming cheaper and
	cheaper, various types of IoT devices become available in the		cheaper, various types of IoT devices become available in the
	consumer market at affordable price. But on the downside, the main		consumer market at affordable price. But on the downside, the main
	threat being most of these IoT devices are bought off-the-shelf and		threat being most of these IoT devices are bought off-the-shelf and
	most manufacturers haven't considered security in the product design.		most manufacturers haven't considered security in the product design.
	IoT devices deployed in home networks can be easily compromised, they		IoT devices deployed in home networks can be easily compromised, they
	do not have an easy mechanism to upgrade, and IoT manufactures may		do not have an easy mechanism to upgrade, and IoT manufactures may
	cease manufacture and/or discontinue patching vulnerabilities on IoT		cease manufacture and/or discontinue patching vulnerabilities on IoT
	devices (Sections 5.4 and 5.5 of [I-D.irtf-t2trg-iot-seccons]).		devices (Sections 5.4 and 5.5 of [RFC8576]). However, these
	However, these vulnerable and compromised devices will continue to be		vulnerable and compromised devices will continue to be used for a
	used for a long period of time in the home, and the end-user does not		long period of time in the home, and the end-user does not know that
	know that IoT devices in his/her home are compromised. The		IoT devices in his/her home are compromised. The compromised IoT
	compromised IoT devices are typically used for launching DDoS attacks		devices are typically used for launching DDoS attacks (Section 3 of
	(Section 3 of [I-D.irtf-t2trg-iot-seccons]) on victims while the		[RFC8576]) on victims while the owner/administrator of the home
	owner/administrator of the home network is not aware about such		network is not aware about such misbehaviors. Similar to other DDoS
	misbehaviors. Similar to other DDoS attacks, the victim in this		attacks, the victim in this attack can be an application server, a
	attack can be an application server, a host, a router, a firewall, or		host, a router, a firewall, or an entire network.
	an entire network.
	Nowadays, network devices in a home network offer network security		Nowadays, network devices in a home network offer network security
	(e.g., firewall or Intrusion Protection System (IPS) service on a		(e.g., firewall or Intrusion Protection System (IPS) service on a
	home router) to protect the devices connected to the home network		home router) to protect the devices connected to the home network
	from both external and internal attacks. Over the years several		from both external and internal attacks. Over the years several
	techniques have been identified to detect DDoS attacks, some of these		techniques have been identified to detect DDoS attacks, some of these
	techniques can be enabled on home network devices but most of them		techniques can be enabled on home network devices but most of them
	are used in the Internet Service Provider (ISP)'s network. The ISP		are used in the Internet Service Provider (ISP)'s network. The ISP
	offering DDoS mitigation service can detect outgoing DDoS attack		offering DDoS mitigation service can detect outgoing DDoS attack
	traffic originating from its subscribers or the ISP may receive		traffic originating from its subscribers or the ISP may receive
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	| ||		| ||
	+-----+-++----+		+-----+-++----+
	|Attack Source|		|Attack Source|
	+-------------+		+-------------+
	Figure 1: Call Home Reference Architecture		Figure 1: Call Home Reference Architecture
	It is out of the scope of this document to identify an exhaustive		It is out of the scope of this document to identify an exhaustive
	list of such deployments.		list of such deployments.
	2. Notational Conventions and 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
	capitals, as shown here.		capitals, as shown here.
	The reader should be familiar with the terms defined in		The reader should be familiar with the terms defined in
	[I-D.ietf-dots-requirements].		[I-D.ietf-dots-requirements].
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	different port number. Using this TCP connection, the DOTS		different port number. Using this TCP connection, the DOTS
	server initiates a TLS connection to the DOTS client.		server initiates a TLS connection to the DOTS client.
	The Happy Eyeballs mechanism explained in Section 4.3 of		The Happy Eyeballs mechanism explained in Section 4.3 of
	[I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS		[I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS
	connections.		connections.
	2. Using this (D)TLS connection, the DOTS client may request,		2. Using this (D)TLS connection, the DOTS client may request,
	withdraw, or retrieve the status of mitigation requests.		withdraw, or retrieve the status of mitigation requests.
	3.2. DOTS Signal Channel Extension		3.2. Heartbeat Mechanism
	3.2.1. Mitigation Request		The Heartbeat mechanism used for the Call Home deviates from the one
			defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This
			section specifies the behavior to be followed by DOTS agents for the
			Call Home.
			Once the (D)TLS section is established between the DOTS agents, the
			DOTS client contacts the DOTS server to retrieve the session
			configuration parameters (Section 4.5 of
			[I-D.ietf-dots-signal-channel]). The DOTS server adjusts the
			'heartbeat-interval' to accommodate binding timers used by on-path
			NATs and firewalls. Heartbeats will be then exchanged by the DOTS
			agents following the instructions retrieved using the signal channel
			session configuration exchange.
			It is the responsibility of DOTS servers to ensure that on-path
			translators/firewalls are maintaining a binding so that the same
			external IP address and/or port number is retained for the DOTS
			signal channel session. A DOTS client MAY trigger their heartbeat
			requests immediately after receiving heartbeat probes from its peer
			DOTS server.
			When an outgoing attack that saturates the outgoing link from the
			DOTS server is detected and reported by a DOTS client, the latter
			MUST continue to use the signal channel even if no traffic is
			received from the DOTS server. It is most likely that the outgoing
			traffic is exceeding the DOTS server domain capacity. As a reminder,
			the DOTS client cannot initiate a (D)TLS connection.
			If the DOTS server receives traffic from the DOTS client, the DOTS
			server MUST continue to use the signal channel even if the missing
			heartbeat allowed threshold is reached.
			If the DOTS server does not receive any traffic from the peer DOTS
			client, the DOTS server sends heartbeat requests to the DOTS client
			and after maximum 'missing-hb-allowed' threshold is reached, the DOTS
			server concludes the session is disconnected. Then, the DOTS server
			MUST try to resume the (D)TLS session.
			3.3. DOTS Signal Channel Extension
			3.3.1. Mitigation Request
	This specification extends the mitigation request defined in		This specification extends the mitigation request defined in
	Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the		Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the
	attacker source prefixes and source port numbers. The DOTS client		attacker source prefixes and source port numbers. The DOTS client
	conveys the following new parameters in the CBOR body of the		conveys the following new parameters in the CBOR body of the
	mitigation request:		mitigation request:
	source-prefix: A list of attacker prefixes used to attack the		source-prefix: A list of attacker prefixes used to attack the
	target. Prefixes are represented using Classless Inter-Domain		target. Prefixes are represented using Classless Inter-Domain
	Routing (CIDR) notation [RFC4632].		Routing (CIDR) notation [RFC4632].
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 45 ¶
	information because 'target-uri' and 'target-fqdn' are optional		information because 'target-uri' and 'target-fqdn' are optional
	attributes and 'alias-name' will not be conveyed in a mitigation		attributes and 'alias-name' will not be conveyed in a mitigation
	request.		request.
	In order to help attack source identification by a DOTS server, the		In order to help attack source identification by a DOTS server, the
	DOTS client SHOULD include in its mitigation request additional		DOTS client SHOULD include in its mitigation request additional
	information such as 'source-port-range' or 'source-icmp-type-range'.		information such as 'source-port-range' or 'source-icmp-type-range'.
	The DOTS client may not include such information if 'source-prefix'		The DOTS client may not include such information if 'source-prefix'
	conveys an IPv6 address/prefix.		conveys an IPv6 address/prefix.
			Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
			'true') are allowed; DOTS clients MUST NOT send requests with
			'trigger-mitigation' set to 'false'. Such requests MUST be discarded
			by the DOTS server with a 4.00 (Bad Request).
	If a Carrier Grade NAT (CGN, including NAT64) is located between the		If a Carrier Grade NAT (CGN, including NAT64) is located between the
	DOTS client domain and DOTS server domain, communicating an external		DOTS client domain and DOTS server domain, communicating an external
	IP address in a mitigation request is likely to be discarded by the		IP address in a mitigation request is likely to be discarded by the
	DOTS server because the external IP address is not visible locally to		DOTS server because the external IP address is not visible locally to
	the DOTS server (see Figure 3). The DOTS server is only aware of the		the DOTS server (see Figure 3). The DOTS server is only aware of the
	internal IP addresses/prefixes bound to its domain. Thus, the DOTS		internal IP addresses/prefixes bound to its domain. Thus, the DOTS
	client MUST NOT include the external IP address and/or port number		client MUST NOT include the external IP address and/or port number
	identifying the suspect attack source, but MUST include the internal		identifying the suspect attack source, but MUST include the internal
	IP address and/or port number. To that aim, the DOTS client SHOULD		IP address and/or port number. To that aim, the DOTS client SHOULD
	rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the		rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the
	internal IP address and port number which are mapped to an external		internal IP address and port number which are mapped to an external
	IP address and port number.		IP address and port number.
	N | .-------------------.		N | .-------------------.
	E | ( )-.		E | ( )-.
	T | .' '		T | .' '
	W | ( )		W | ( )
	O | ( DOTS server -'		O | ( DOTS client -'
	R | '-( )		R | '-( )
	K | '-------+-----------'		K | '-------+-----------'
	| |		| |
	P | |		P | |
	R | +---+---+		R | +---+---+
	O | | CGN | External Realm		O | | CGN | External Realm
	V |..............|.......|......................		V |..............| |......................
	I | | | Internel Realm		I | | | Internal Realm
	D | +---+---+		D | +---+---+
	E | |		E | |
	R | |		R | |
	--- |		--- |
	.---------+---------.		.---------+---------.
	( )-.		( )-.
	.' Source Network '		.' Source Network '
	( )		( )
	( DOTS client -'		( DOTS server -'
	'-( )		'-( )
	'------+------------'		'------+------------'
	|		|
	+-----+-------+		+-----+-------+
	|Attack Source|		|Attack Source|
	+-------------+		+-------------+
	Figure 3: Example of a CGN Between DOTS Domains		Figure 3: Example of a CGN between DOTS Domains
	If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the		If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the
	provider's domain to service its customers, the identification of an		provider's domain to service its customers, the identification of an
	attack source bound to an IPv4 address/prefix MUST also rely on		attack source bound to an IPv4 address/prefix MUST also rely on
	source port numbers because the same IPv4 address is assigned to		source port numbers because the same IPv4 address is assigned to
	multiple customers. The port information is required to		multiple customers. The port information is required to
	unambiguously identify the source of an attack.		unambiguously identify the source of an attack.
	The DOTS server MUST check that the 'source-prefix' is within the		The DOTS server MUST check that the 'source-prefix' is within the
	scope of the DOTS server domain in the Call Home scenario. Note that		scope of the DOTS server domain in the Call Home scenario. Note that
	in such scenario, the DOTS server considers, by default, that any		in such scenario, the DOTS server considers, by default, that any
	routeable IP prefix enclosed in 'target-prefix' is within the scope		routeable IP prefix enclosed in 'target-prefix' is within the scope
	of the DOTS client. Invalid mitigation requests are handled as per		of the DOTS client. Invalid mitigation requests are handled as per
	Section 4.4.1 of [I-D.ietf-dots-signal-channel].		Section 4.4.1 of [I-D.ietf-dots-signal-channel].
	If a translator is enabled on the boundaries of the domain hosting		If a translator is enabled on the boundaries of the domain hosting
	the DOTS server (a CPE with NAT enabled as shown in Figure 4,		the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4
	typically), the DOTS server uses the attack traffic information		and 5), the DOTS server uses the attack traffic information conveyed
	conveyed in a mitigation request to find the internal source IP		in a mitigation request to find the internal source IP address of the
	address of the compromised device and blocks the traffic from the		compromised device and blocks the traffic from the compromised device
	compromised device traffic to the attack target until the mitigation		traffic to the attack target until the mitigation request is
	request is withdrawn. Doing so allows to isolate the suspicious		withdrawn. Doing so allows to isolate the suspicious device while
	device while avoiding to disturb other services.		avoiding to disturb other services.
	.-------------------.		.-------------------.
	( )-.		( )-.
	.' Network Provider '		.' Network Provider '
	( (DMS) )		( (DMS) )
	( DOTS server -'		( DOTS client -'
	'-( )		'-( )
	'------+------------'		'------+------------'
	|		|
	|		|
	--- +--+----+		--- +--+----+
	S | | CPE | External Realm		S | | CPE | External Realm
	O |..............|.......|................		O |..............| |................
	U | | NAT | Internel Realm		U | | NAT | Internal Realm
	R | +-------+		R | +-------+
	C | |		C | |
	E | .--------+----------.		E | .--------+----------.
	| ( )-.		| ( )-.
	N | .' '		N | .' '
	E | ( )		E | ( )
	T | ( DOTS client -'		T | ( DOTS server -'
	W | '-( )		W | '-( )
	O | '------+------------'		O | '------+------------'
	R | |		R | |
	K | +-----+-------+		K | +-----+-------+
	| |Attack Source|		| |Attack Source|
	+-------------+		+-------------+
	Figure 4: Example of a DOTS Client Domain with a NAT Embeded in a CPE		Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE
			.-------------------.
			( )-.
			.' Network Provider '
			( (DMS) )
			( DOTS client -'
			'-( )
			'---------+---------'
			|
			|
			--- +-----+-----+
			S | | CPE/NAT | External Realm
			O |..............| |................
			U | |DOTS server| Internal Realm
			R | +-----------+
			C | |
			E | .--------+----------.
			| ( )-.
			N | .' '
			E | ( Local Area Network )
			T | ( -'
			W | '-( )
			O | '------+------------'
			R | |
			K | +-----+-------+
			| |Attack Source|
			+-------------+
			Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE
	The DOTS server domain administrator consent MAY be required to block		The DOTS server domain administrator consent MAY be required to block
	the traffic from the compromised device to the attack target. An		the traffic from the compromised device to the attack target. An
	implementation MAY have a configuration knob to block the traffic		implementation MAY have a configuration knob to block the traffic
	from the compromised device to the attack target with or without DOTS		from the compromised device to the attack target with or without DOTS
	server domain administrator consent. If the attack traffic is		server domain administrator consent. If the attack traffic is
	blocked, the DOTS server informs the DOTS client that the attack is		blocked, the DOTS server informs the DOTS client that the attack is
	being mitigated.		being mitigated.
	If the attack traffic information is identified by the DOTS server or		If the attack traffic information is identified by the DOTS server or
	the DOTS server domain administrator as legitimate traffic, the		the DOTS server domain administrator as legitimate traffic, the
	skipping to change at page 12, line 35 ¶		skipping to change at page 14, line 17 ¶
	The DOTS client is informed about the progress of the attack		The DOTS client is informed about the progress of the attack
	mitigation following the rules in [I-D.ietf-dots-signal-channel].		mitigation following the rules in [I-D.ietf-dots-signal-channel].
	For example, if the DOTS server is embedded in a CPE, it can program		For example, if the DOTS server is embedded in a CPE, it can program
	the packet processor to punt all the traffic from the compromised		the packet processor to punt all the traffic from the compromised
	device to the target to slow path. The CPE inspects the punted slow		device to the target to slow path. The CPE inspects the punted slow
	path traffic to detect and block the outgoing DDoS attack traffic or		path traffic to detect and block the outgoing DDoS attack traffic or
	quarantine the device (e.g., using MAC level filtering) until it is		quarantine the device (e.g., using MAC level filtering) until it is
	remediated, and notifies the CPE administrator about the compromised		remediated, and notifies the CPE administrator about the compromised
	device.		device.
	3.2.2. DOTS Signal Call Home YANG Module		3.3.2. DOTS Signal Call Home YANG Module
	3.2.2.1. Tree Structure		3.3.2.1. Tree Structure
	This document augments the "dots-signal-channel" DOTS signal YANG		This document augments the "dots-signal-channel" DOTS signal YANG
	module defined in [I-D.ietf-dots-signal-channel] for signaling the		module defined in [I-D.ietf-dots-signal-channel] for signaling the
	attack traffic information. This document defines the YANG module		attack traffic information. This document defines the YANG module
	"ietf-dots-call-home", which has the following tree structure:		"ietf-dots-call-home", which has the following tree structure:
	module: ietf-dots-call-home		module: ietf-dots-call-home
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--rw source-prefix* inet:ip-prefix {source-signaling}?		+--rw source-prefix* inet:ip-prefix {source-signaling}?
	+--rw source-port-range* [lower-port] {source-signaling}?		+--rw source-port-range* [lower-port] {source-signaling}?
	| +--rw lower-port inet:port-number		| +--rw lower-port inet:port-number
	| +--rw upper-port? inet:port-number		| +--rw upper-port? inet:port-number
	+--rw source-icmp-type-range*		+--rw source-icmp-type-range*
	| [lower-type] {source-signaling}?		| [lower-type] {source-signaling}?
	+--rw lower-type uint8		+--rw lower-type uint8
	+--rw upper-type? uint8		+--rw upper-type? uint8
	3.2.2.2. YANG Module		3.3.2.2. YANG Module
	This module uses the common YANG types defined in [RFC6991].		This module uses the common YANG types defined in [RFC6991].
	<CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang"		<CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang"
	module ietf-dots-call-home {		module ietf-dots-call-home {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
	prefix call-home;		prefix call-home;
	skipping to change at page 13, line 46 ¶		skipping to change at page 15, line 19 ¶
	"RFC YYYY: Distributed Denial-of-Service Open Threat		"RFC YYYY: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification";		Signaling (DOTS) Signal 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>
	Editor: Konda, Tirumaleswar Reddy		Author: Konda, Tirumaleswar Reddy
	<mailto:TirumaleswarReddy_Konda@McAfee.com>;		<mailto:TirumaleswarReddy_Konda@McAfee.com>;
	Editor: Mohamed Boucadair		Author: Mohamed Boucadair
	<mailto:mohamed.boucadair@orange.com>;		<mailto:mohamed.boucadair@orange.com>;
	Editor: Jon Shallow		Author: Jon Shallow
	<mailto:ietf-supjps@jpshallow.com>";		<mailto:ietf-supjps@jpshallow.com>";
	description		description
	"This module contains YANG definitions for the signaling		"This module contains YANG definitions for the signaling
	messages exchanged between a DOTS client and a DOTS server		messages exchanged between a DOTS client and a DOTS server
	for the Call Home deployment scenario.		for the Call Home deployment scenario.
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2019 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	skipping to change at page 17, line 37 ¶		skipping to change at page 19, line 14 ¶
	Name: ietf-call-home		Name: ietf-call-home
	Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home		Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
	Maintained by IANA: N		Maintained by IANA: N
	Prefix: call-home		Prefix: call-home
	Reference: RFC XXXX		Reference: RFC XXXX
	5. Security Considerations		5. Security Considerations
	This document deviates from classic DOTS signal channel usage by		This document deviates from classic DOTS signal channel usage by
	having the DOTS server initiate the TLS or DTLS connection. DOTS		having the DOTS server initiate the (D)TLS connection. DOTS signal
	signal channel related security considerations discussed in		channel related security considerations discussed in Section 10 of
	Section 10 of [I-D.ietf-dots-signal-channel] MUST be considered.		[I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST
	DOTS agents MUST authenticate each other using (D)TLS before a DOTS		authenticate each other using (D)TLS before a DOTS signal channel
	signal channel session is considered valid.		session is considered valid.
	An attacker may launch a DoS attack on the DOTS client by having it		An attacker may launch a DoS attack on the DOTS client by having it
	perform computationally expensive operations, before deducing that		perform computationally expensive operations, before deducing that
	the attacker doesn't possess a valid key. For instance, in TLS 1.3		the attacker doesn't possess a valid key. For instance, in TLS 1.3
	[RFC8446], the ServerHello message contains a Key Share value based		[RFC8446], the ServerHello message contains a Key Share value based
	on an expensive asymmetric key operation for key establishment.		on an expensive asymmetric key operation for key establishment.
	Common precautions mitigating DoS attacks are recommended, such as		Common precautions mitigating DoS attacks are recommended, such as
	temporarily blacklisting the source address after a set number of		temporarily blacklisting the source address after a set number of
	unsuccessful authentication attempts.		unsuccessful authentication attempts.
	DOTS servers may not blindly trust mitigation requests from DOTS		DOTS servers may not blindly trust mitigation requests from DOTS
	clients. For example, DOTS servers can use the attack flow		clients. For example, DOTS servers can use the attack flow
	information in a mitigation request to enable full-fledged packet		information in a mitigation request to enable full-fledged packet
	inspection function to inspect all the traffic from the compromised		inspection function to inspect all the traffic from the compromised
	to the target or to re-direct the traffic from the compromised device		to the target or to re-direct the traffic from the compromised device
	to the target to a DDoS mitigation system to scrub the suspicious		to the target to a DDoS mitigation system to scrub the suspicious
	traffic. DOTS servers can also seek the consent of DOTS server		traffic. DOTS servers can also seek the consent of DOTS server
	domain administrator to block the traffic from the compromised device		domain administrator to block the traffic from the compromised device
	to the target (see Section 3.2.1).		to the target (see Section 3.3.1).
	6. Privacy Considerations		6. Privacy Considerations
	The considerations discussed in [RFC6973] were taken into account to		The considerations discussed in [RFC6973] were taken into account to
	assess whether the DOTS Call Home extension introduces privacy		assess whether the DOTS Call Home extension introduces privacy
	threats.		threats.
	Concretely, the protocol does not leak any new information that can		Concretely, the protocol does not leak any new information that can
	be used to ease surveillance. In particular, the DOTS server is not		be used to ease surveillance. In particular, the DOTS server is not
	required to share information that is local to its network (e.g.,		required to share information that is local to its network (e.g.,
	skipping to change at page 18, line 45 ¶		skipping to change at page 20, line 20 ¶
	The DOTS Call Home extension is only advisory in nature. Concretely,		The DOTS Call Home extension is only advisory in nature. Concretely,
	the DOTS Call Home extension does not impose any action to be		the DOTS Call Home extension does not impose any action to be
	enforced within the home network; it is up to the DOTS server (and/or		enforced within the home network; it is up to the DOTS server (and/or
	network administrator) to decide whether and which actions are		network administrator) to decide whether and which actions are
	required.		required.
	Moreover, the DOTS Call Home extension avoids misattribution by		Moreover, the DOTS Call Home extension avoids misattribution by
	appropriately identifying the network to which a suspect attack		appropriately identifying the network to which a suspect attack
	source belongs to (e.g., address sharing issues discussed in		source belongs to (e.g., address sharing issues discussed in
	Section 3.2.1).		Section 3.3.1).
	Triggers to send a DOTS mitigation request to a DOTS server are		Triggers to send a DOTS mitigation request to a DOTS server are
	deployment-specific. For example, a DOTS client may rely on the		deployment-specific. For example, a DOTS client may rely on the
	output of some DDoS detection systems deployed within the DOTS client		output of some DDoS detection systems deployed within the DOTS client
	domain to detect potential outbound DDoS attacks or on abuse claims		domain to detect potential outbound DDoS attacks or on abuse claims
	received from remote victim networks. Such DDoS detection and		received from remote victim networks. Such DDoS detection and
	mitigation techniques are not meant to track the activity of users,		mitigation techniques are not meant to track the activity of users,
	but to protect the Internet and avoid altering the IP reputation of		but to protect the Internet and avoid altering the IP reputation of
	the DOTS client domain.		the DOTS client domain.
	skipping to change at page 19, line 32 ¶		skipping to change at page 21, line 13 ¶
	Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.		Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-dots-signal-channel]		[I-D.ietf-dots-signal-channel]
	K, R., Boucadair, M., Patil, P., Mortensen, A., and N.		K, R., Boucadair, M., Patil, P., Mortensen, A., and N.
	Teague, "Distributed Denial-of-Service Open Threat		Teague, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification", draft-		Signaling (DOTS) Signal Channel Specification", draft-
	ietf-dots-signal-channel-31 (work in progress), March		ietf-dots-signal-channel-34 (work in progress), May 2019.
	2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 20, line 32 ¶		skipping to change at page 22, line 12 ¶
	Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01		Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01
	(work in progress), January 2019.		(work in progress), January 2019.
	[I-D.ietf-dots-requirements]		[I-D.ietf-dots-requirements]
	Mortensen, A., K, R., and R. Moskowitz, "Distributed		Mortensen, A., K, R., and R. Moskowitz, "Distributed
	Denial of Service (DDoS) Open Threat Signaling		Denial of Service (DDoS) Open Threat Signaling
	Requirements", draft-ietf-dots-requirements-22 (work in		Requirements", draft-ietf-dots-requirements-22 (work in
	progress), March 2019.		progress), March 2019.
	[I-D.ietf-dots-server-discovery]		[I-D.ietf-dots-server-discovery]
	Boucadair, M., K, R., and P. Patil, "Distributed-Denial-		Boucadair, M. and R. K, "Distributed-Denial-of-Service
	of-Service Open Threat Signaling (DOTS) Server Discovery",		Open Threat Signaling (DOTS) Server Discovery", draft-
	draft-ietf-dots-server-discovery-01 (work in progress),		ietf-dots-server-discovery-03 (work in progress), May
	April 2019.		2019.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,		Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
	Open Threat Signaling", draft-ietf-dots-use-cases-17 (work		Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
	in progress), January 2019.		in progress), January 2019.
	[I-D.irtf-t2trg-iot-seccons]
	Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
	the-Art and Challenges for the Internet of Things
	Security", draft-irtf-t2trg-iot-seccons-16 (work in
	progress), December 2018.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340,		Congestion Control Protocol (DCCP)", RFC 4340,
	DOI 10.17487/RFC4340, March 2006,		DOI 10.17487/RFC4340, March 2006,
	<https://www.rfc-editor.org/info/rfc4340>.		<https://www.rfc-editor.org/info/rfc4340>.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
	2006, <https://www.rfc-editor.org/info/rfc4632>.		2006, <https://www.rfc-editor.org/info/rfc4632>.
	skipping to change at page 22, line 22 ¶		skipping to change at page 23, line 41 ¶
	Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513,		Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513,
	DOI 10.17487/RFC8513, January 2019,		DOI 10.17487/RFC8513, January 2019,
	<https://www.rfc-editor.org/info/rfc8513>.		<https://www.rfc-editor.org/info/rfc8513>.
	[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.		[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
	Jacquenet, "An Inventory of Transport-Centric Functions		Jacquenet, "An Inventory of Transport-Centric Functions
	Provided by Middleboxes: An Operator Perspective",		Provided by Middleboxes: An Operator Perspective",
	RFC 8517, DOI 10.17487/RFC8517, February 2019,		RFC 8517, DOI 10.17487/RFC8517, February 2019,
	<https://www.rfc-editor.org/info/rfc8517>.		<https://www.rfc-editor.org/info/rfc8517>.
	Authors' Addresses		[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
			Things (IoT) Security: State of the Art and Challenges",
			RFC 8576, DOI 10.17487/RFC8576, April 2019,
			<https://www.rfc-editor.org/info/rfc8576>.
			Authors' Addresses
	Tirumaleswar Reddy		Tirumaleswar Reddy
	McAfee, Inc.		McAfee, Inc.
	Embassy Golf Link Business Park		Embassy Golf Link Business Park
	Bangalore, Karnataka 560071		Bangalore, Karnataka 560071
	India		India
	Email: kondtir@gmail.com		Email: kondtir@gmail.com
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
End of changes. 35 change blocks.
	78 lines changed or deleted		149 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/