draft-ietf-dots-signal-call-home-05.txt		draft-ietf-dots-signal-call-home-06.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: January 31, 2020 Orange		Expires: March 13, 2020 Orange
	J. Shallow		J. Shallow
	July 30, 2019		September 10, 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-05		draft-ietf-dots-signal-call-home-06
	Abstract		Abstract
	This document specifies the DOTS signal channel Call Home, which		This document specifies the DOTS signal channel Call Home, which
	enables a DOTS server to initiate a secure connection to a DOTS		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).
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 31, 2020.		This Internet-Draft will expire on March 13, 2020.
	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 45 ¶		skipping to change at page 2, line 45 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5		1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6		1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
	1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 7		1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12		3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12
	3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 13		3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13
	3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 14		3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13
	3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 14		3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14
	3.3.2. Address Sharing Considerations . . . . . . . . . . . 17		3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15
	3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 20		3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		3.3.2. Address Sharing Considerations . . . . . . . . . . . 18
	4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 24		3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 21
	4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 24		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 25		4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 25
	4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 26		4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 26
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 26		4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 27
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27		4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 28
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27		5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
	9.1. Normative References . . . . . . . . . . . . . . . . . . 28		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	9.2. Informative References . . . . . . . . . . . . . . . . . 29		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 31		9.1. Normative References . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		9.2. Informative References . . . . . . . . . . . . . . . . . 31
			Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	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 [RFC4732]. Such information is sent by a DOTS client to one		attack [RFC4732]. Such information is sent by a DOTS client to one
	or multiple DOTS servers so that appropriate mitigation actions are		or multiple DOTS servers so that appropriate mitigation actions are
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 41 ¶
	A high-level DOTS Call Home functional architecture is shown in		A high-level DOTS Call Home functional architecture is shown in
	Figure 1. Attack source(s) are within the DOTS server domain.		Figure 1. Attack source(s) are within the DOTS server domain.
	Scope		Scope
	+.-.-.-.-.-.-.-.-.-.-.-.+		+.-.-.-.-.-.-.-.-.-.-.-.+
	+---------------+ : +-------------+ :		+---------------+ : +-------------+ :
	| Alert/DMS/ | ~~~:~~~ | Call Home | :		| Alert/DMS/ | ~~~:~~~ | Call Home | :
	| Peer DMS/... | : | DOTS client | :		| Peer DMS/... | : | DOTS client | :
	+---------------+ : +------+------+ :		+---------------+ : +------+------+ :
	: | :		: | :
	: | :		: | :
	: | :		: | :
	+---------------+ : +------+------+ :		+---------------+ : +------+------+ :
	| Attack | ~~~:~~~ | Call Home | :		| Attack | ~~~:~~~ | Call Home | :
	| Source(s) | : | DOTS server | :		| Source(s) | : | DOTS server | :
	+---------------+ : +-------------+ :		+---------------+ : +-------------+ :
	+.-.-.-.-.-.-.-.-.-.-.-.+		+.-.-.-.-.-.-.-.-.-.-.-.+
	Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture		Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture
	A DOTS client relies upon a variety of triggers to make use of the		A DOTS client relies upon a variety of triggers to make use of the
	Call Home function (e.g., scrubbing the traffic from the attack		Call Home function (e.g., scrubbing the traffic from the attack
	source, receiving an alert from an attack target, a peer DDoS		source, receiving an alert from an attack target, a peer DDoS
	Mitigation System (DMS), or a transit provider). The definition of		Mitigation System (DMS), or a transit provider). The definition of
	these triggers is deployment-specific. It is therefore out of the		these triggers is deployment-specific. It is therefore out of the
	scope of this document to elaborate on how these triggers are made		scope of this document to elaborate on how these triggers are made
	available to a Call Home DOTS client.		available to a Call Home DOTS client.
	In a typical deployment scenario, the Call Home DOTS server is		In a typical deployment scenario, the Call Home DOTS server is
	enabled on a Customer Premises Equipment (CPE), which is aligned with		enabled on a Customer Premises Equipment (CPE), which is aligned with
	skipping to change at page 13, line 36 ¶		skipping to change at page 13, line 36 ¶
	[I-D.ietf-dots-signal-channel] is used for initiating (D)TLS		[I-D.ietf-dots-signal-channel] is used for initiating (D)TLS
	connections.		connections.
	2. Using this (D)TLS connection, the Call Home DOTS client may		2. Using this (D)TLS connection, the Call Home DOTS client may
	request, withdraw, or retrieve the status of mitigation requests.		request, withdraw, or retrieve the status of mitigation requests.
	The Call Home DOTS client supplies the source information by		The Call Home DOTS client supplies the source information by
	means of new attributes defined in Section 3.3.1.		means of new attributes defined in Section 3.3.1.
	The Heartbeat mechanism used for the DOTS Call Home deviates from		The Heartbeat mechanism used for the DOTS Call Home deviates from
	the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel].		the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel].
	Section 3.2 specifies the behavior to be followed by Call Home		Section 3.2.1 specifies the behavior to be followed by Call Home
	DOTS agents.		DOTS agents.
	3.2. Heartbeat Mechanism		3.2. DOTS Signal Channel Variations
			3.2.1. Heartbeat Mechanism
	Once the (D)TLS section is established between the DOTS agents, the		Once the (D)TLS section is established between the DOTS agents, the
	Call Home DOTS client contacts the Call Home DOTS server to retrieve		Call Home DOTS client contacts the Call Home DOTS server to retrieve
	the session configuration parameters (Section 4.5 of		the session configuration parameters (Section 4.5 of
	[I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts		[I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts
	the 'heartbeat-interval' to accommodate binding timers used by on-		the 'heartbeat-interval' to accommodate binding timers used by on-
	path NATs and firewalls. Heartbeats will be then exchanged by the		path NATs and firewalls. Heartbeats will be then exchanged by the
	DOTS agents following the instructions retrieved using the signal		DOTS agents following the instructions retrieved using the signal
	channel session configuration exchange.		channel session configuration exchange.
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 28 ¶
	client, the Call Home DOTS server MUST continue to use the DOTS		client, the Call Home DOTS server MUST continue to use the DOTS
	signal channel even if the missing heartbeats allowed threshold		signal channel even if the missing heartbeats allowed threshold
	('missing-hb-allowed') is reached.		('missing-hb-allowed') is reached.
	If the Call Home DOTS server does not receive any traffic from the		If the Call Home DOTS server does not receive any traffic from the
	peer Call Home DOTS client during the time span required to exhaust		peer Call Home DOTS client during the time span required to exhaust
	the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server		the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server
	concludes the session is disconnected. Then, the Call Home DOTS		concludes the session is disconnected. Then, the Call Home DOTS
	server MUST try to resume the (D)TLS session.		server MUST try to resume the (D)TLS session.
			3.2.2. Redirected Signaling
			A Call Home DOTS server MUST NOT support the Redirected Signaling
			mechanism as specified in Section 4.6 of
			[I-D.ietf-dots-signal-channel] (i.e., a 5.03 response that conveys an
			alternate DOTS server's FQDN or alternate DOTS server's IP
			address(es)). A Call Home DOTS client MUST silently discard such
			message as only a Call Home DOTS server can initiate a new (D)TLS
			connection.
			If a Call Home DOTS client wants to redirect a Call Home DOTS server
			to another Call Home DOTS client, it MUST send a Non-confirmable PUT
			request to the predefined resource ".well-known/dots/redirect" with
			the new Call Home DOTS client FQDN or IP address in the body of the
			PUT similar to what is described in Section 4.6 of
			[I-D.ietf-dots-signal-channel]. Furthermore, a new clause called
			'ttl" is defined to return the Time to live (TTL) of the alternate
			Call Home DOTS client.
			On receipt of this PUT request, the Call Home DOTS server responds
			with a 2.01 (Created), closes this connection and establishes a
			connection with the new Call Home DOTS client. The processing of the
			TTL is defined in Section 4.6 of [I-D.ietf-dots-signal-channel]. If
			the Call Home DOTS server cannot service the PUT request, the
			response is rejected with a 4.00 (bad Request).
			Figure 8 shows a PUT request example to convey the alternate Call
			Home DOTS client 'alt-call-home-client.example' together with its IP
			addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of
			this alternate Call Home DOTS client is 10 minutes.
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "redirect"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "mid=123"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:redirected-signal": {
			"ietf-dots-call-home:alt-ch-client":
			"alt-call-home-client.example",
			"ietf-dots-call-home:alt-ch-client-record": [
			"2001:db8:6401::1",
			"2001:db8:6401::2"
			],
			"ietf-dots-call-home:ttl": 600
			}
			Figure 8: Example of a PUT Request for Redirected Signaling
	3.3. DOTS Signal Channel Extension		3.3. DOTS Signal Channel Extension
	3.3.1. Mitigation Request		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 attack		Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attack
	source information (e.g., source prefixes, source port numbers). The		source information (e.g., source prefixes, source port numbers). The
	DOTS client conveys the following new parameters in the CBOR body of		DOTS client conveys the following new parameters in the CBOR body of
	the mitigation request:		the mitigation request:
	skipping to change at page 15, line 52 ¶		skipping to change at page 17, line 11 ¶
	Address sharing implications on the setting of source information		Address sharing implications on the setting of source information
	('source-prefix', 'source-port-range') are discussed in		('source-prefix', 'source-port-range') are discussed in
	Section 3.3.2.		Section 3.3.2.
	Only immediate mitigation requests (i.e., 'trigger-mitigation' set to		Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
	'true') are allowed; Call Home DOTS clients MUST NOT send requests		'true') are allowed; Call Home DOTS clients MUST NOT send requests
	with 'trigger-mitigation' set to 'false'. Such requests MUST be		with 'trigger-mitigation' set to 'false'. Such requests MUST be
	discarded by the Call Home DOTS server with a 4.00 (Bad Request).		discarded by the Call Home DOTS server with a 4.00 (Bad Request).
	An example of a mitigation request sent by a Call Home DOTS client is		An example of a mitigation request sent by a Call Home DOTS client is
	shown in Figure 8.		shown in Figure 9.
	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=56"		Uri-Path: "mid=56"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 16, line 29 ¶		skipping to change at page 17, line 37 ¶
	],		],
	"ietf-dots-call-home:source-prefix": [		"ietf-dots-call-home:source-prefix": [
	"2001:db8:123::/128"		"2001:db8:123::/128"
	],		],
	"lifetime": 3600		"lifetime": 3600
	}		}
	]		]
	}		}
	}		}
	Figure 8: An Example of Mitigation Request Issued by a Call Home DOTS		Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS
	Client		Client
	The Call Home DOTS server MUST check that the 'source-prefix' is		The Call Home DOTS server MUST check that the 'source-prefix' is
	within the scope of the Call Home DOTS server domain. Note that in a		within the scope of the Call Home DOTS server domain. Note that in a
	DOTS Call Home scenario, the Call Home DOTS server considers, by		DOTS Call Home scenario, the Call Home DOTS server considers, by
	default, that any routeable IP prefix enclosed in 'target-prefix' is		default, that any routeable IP prefix enclosed in 'target-prefix' is
	within the scope of the Call Home DOTS client. Invalid mitigation		within the scope of the Call Home DOTS client. Invalid mitigation
	requests are handled as per Section 4.4.1 of		requests are handled as per Section 4.4.1 of
	[I-D.ietf-dots-signal-channel].		[I-D.ietf-dots-signal-channel].
	skipping to change at page 17, line 38 ¶		skipping to change at page 18, line 46 ¶
	The DOTS agents follow the same procedures specified in		The DOTS agents follow the same procedures specified in
	[I-D.ietf-dots-signal-channel] for managing a mitigation request.		[I-D.ietf-dots-signal-channel] for managing a mitigation request.
	3.3.2. Address Sharing Considerations		3.3.2. Address Sharing Considerations
	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
	Call Home DOTS server because the external IP address is not visible		Call Home DOTS server because the external IP address is not visible
	locally to the Call Home DOTS server (see Figure 9). The Call Home		locally to the Call Home DOTS server (see Figure 10). The Call Home
	DOTS server is only aware of the internal IP addresses/prefixes bound		DOTS server is only aware of the internal IP addresses/prefixes bound
	to its domain. Thus, the Call Home DOTS client MUST NOT include the		to its domain. Thus, the Call Home DOTS client MUST NOT include the
	external IP address and/or port number identifying the suspect attack		external IP address and/or port number identifying the suspect attack
	source, but MUST include the internal IP address and/or port number.		source, but MUST include the internal IP address and/or port number.
	To that aim, the Call Home DOTS client SHOULD rely on mechanisms,		To that aim, the Call Home DOTS client SHOULD rely on mechanisms,
	such as [RFC8512] or [RFC8513], to retrieve the internal IP address		such as [RFC8512] or [RFC8513], to retrieve the internal IP address
	and port number which are mapped to an external IP address and port		and port number which are mapped to an external IP address and port
	number.		number.
	N | .-------------------.		N | .-------------------.
	skipping to change at page 18, line 34 ¶		skipping to change at page 19, line 36 ¶
	.' Source Network '		.' Source Network '
	( )		( )
	( Call Home -'		( Call Home -'
	'-( DOTS server )		'-( DOTS server )
	'------+------------'		'------+------------'
	|		|
	+-----+-------+		+-----+-------+
	|Attack Source|		|Attack Source|
	+-------------+		+-------------+
	Figure 9: Example of a CGN between DOTS Domains		Figure 10: 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.
	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 Call Home DOTS server (e.g., a CPE with NAT enabled as shown in		the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in
	Figures 10 and 11), the Call Home DOTS server uses the attack traffic		Figures 11 and 12), the Call Home DOTS server uses the attack traffic
	information conveyed in a mitigation request to find the internal		information conveyed in a mitigation request to find the internal
	source IP address of the compromised device and blocks the traffic		source IP address of the compromised device and blocks the traffic
	from the compromised device traffic to the attack target until the		from the compromised device traffic to the attack target until the
	mitigation request is withdrawn. Doing so allows to isolate the		mitigation request is withdrawn. Doing so allows to isolate the
	suspicious device while avoiding to disturb other services.		suspicious device while avoiding to disturb other services.
	.-------------------.		.-------------------.
	( )-.		( )-.
	.' Network Provider (DMS)'		.' Network Provider (DMS)'
	( )		( )
	skipping to change at page 19, line 31 ¶		skipping to change at page 20, line 33 ¶
	N | .' '		N | .' '
	E | ( Call Home )		E | ( Call Home )
	T | ( DOTS server -'		T | ( DOTS server -'
	W | '-( )		W | '-( )
	O | '-------+-----------'		O | '-------+-----------'
	R | |		R | |
	K | +------+------+		K | +------+------+
	| |Attack Source|		| |Attack Source|
	+-------------+		+-------------+
	Figure 10: Example of a DOTS Server Domain with a NAT Embedded in a		Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a
	CPE		CPE
	.-------------------.		.-------------------.
	( )-.		( )-.
	.' Network Provider (DMS) '		.' Network Provider (DMS) '
	( )		( )
	( Call Home -'		( Call Home -'
	'-( DOTS client )		'-( DOTS client )
	'---------+---------'		'---------+---------'
	|		|
	skipping to change at page 20, line 32 ¶		skipping to change at page 21, line 32 ¶
	N | .' '		N | .' '
	E | ( Local Area Network )		E | ( Local Area Network )
	T | ( -'		T | ( -'
	W | '-( )		W | '-( )
	O | '--------+----------'		O | '--------+----------'
	R | |		R | |
	K | +------+------+		K | +------+------+
	| |Attack Source|		| |Attack Source|
	+-------------+		+-------------+
	Figure 11: Example of a Call Home DOTS Server and a NAT Embedded in a		Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a
	CPE		CPE
	3.3.3. DOTS Signal Call Home YANG Module		3.3.3. DOTS Signal Call Home YANG Module
	3.3.3.1. Tree Structure		3.3.3.1. Tree Structure
	This document augments the "ietf-dots-signal-channel" DOTS signal		This document augments the "ietf-dots-signal-channel" DOTS signal
	YANG module defined in [I-D.ietf-dots-signal-channel] for signaling		YANG module defined in [I-D.ietf-dots-signal-channel] for signaling
	the attack traffic information. This document defines the YANG		the attack traffic information. This document defines the YANG
	module "ietf-dots-call-home", which has the following tree structure:		module "ietf-dots-call-home", which has the following tree structure:
	skipping to change at page 21, line 16 ¶		skipping to change at page 22, line 16 ¶
	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
			augment /ietf-signal:dots-signal/ietf-signal:message-type
			/ietf-signal:redirected-signal:
			+--rw alt-ch-client string {call-home}?
			+--rw alt-ch-client-record* inet:ip-address {call-home}?
			+--rw ttl uint32 {call-home}?
	3.3.3.2. YANG Module		3.3.3.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-09-06.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;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference		reference
	"Section 4 of RFC 6991";		"Section 4 of RFC 6991";
	skipping to change at page 22, line 26 ¶		skipping to change at page 23, line 30 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2019-04-25 {		revision 2019-09-06 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Call Home";		Signaling (DOTS) Signal Channel Call Home";
	}		}
	feature source-signaling {		feature source-signaling {
	description		description
	"This feature means that source-related information		"This feature means that source-related information
	can be supplied in mitigation requests.";		can be supplied in mitigation requests. This is
			typically applicable for DOTS Call Home.";
			}
			feature call-home {
			description
			"This feature means that Call Home functionality
			is supported.";
	}		}
	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" {
	if-feature source-signaling;		if-feature source-signaling;
	description "Attacker source details.";		description "Attacker source details.";
	leaf-list source-prefix {		leaf-list source-prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	description		description
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"IPv4 or IPv6 prefix identifying the attacker(s).";
	}		}
	list source-port-range {		list source-port-range {
	key "lower-port";		key "lower-port";
	skipping to change at page 23, line 46 ¶		skipping to change at page 25, line 9 ¶
	must ". >= ../lower-type" {		must ". >= ../lower-type" {
	error-message		error-message
	"The upper ICMP type must be greater than		"The upper ICMP type must be greater than
	or equal to lower ICMP type.";		or equal to lower ICMP type.";
	}		}
	description		description
	"Upper type of the ICMP type range.";		"Upper type of the ICMP type range.";
	}		}
	}		}
	}		}
			augment "/ietf-signal:dots-signal/ietf-signal:message-type/"
			+ "ietf-signal:redirected-signal" {
			if-feature call-home;
			description
			"The alternate Call Home DOTS client.";
			leaf alt-ch-client {
			type string;
			description
			"FQDN of an alternate Call Home DOTS client.";
			}
			leaf-list alt-ch-client-record {
			type inet:ip-address;
			description
			"List of records for the alternate Call Home
			DOTS client.";
			}
			leaf ttl {
			type uint32;
			units "seconds";
			description
			"The Time to live (TTL) of the alternate Call Home
			DOTS client.";
			}
			}
	}		}
	<CODE ENDS>		<CODE ENDS>
	4. IANA Considerations		4. IANA Considerations
	4.1. DOTS Signal Channel Call Home UDP and TCP Port Number		4.1. DOTS Signal Channel Call Home UDP and TCP Port Number
	IANA is requested to assign the port number TBD to the DOTS signal		IANA is requested to assign the port number TBD to the DOTS signal
	channel Call Home protocol for both UDP and TCP from the "Service		channel Call Home protocol for both UDP and TCP from the "Service
	Name and Transport Protocol Port Number Registry" available at:		Name and Transport Protocol Port Number Registry" available at:
	skipping to change at page 24, line 31 ¶		skipping to change at page 26, line 21 ¶
	Reference: RFC XXXX		Reference: RFC XXXX
	The assignment of port number 4647 is strongly suggested (DOTS signal		The assignment of port number 4647 is strongly suggested (DOTS signal
	channel uses port number 4646).		channel uses port number 4646).
	4.2. DOTS Signal Channel CBOR Mappings Registry		4.2. DOTS Signal Channel CBOR Mappings Registry
	This specification registers the 'source-prefix', 'source-port-		This specification registers the 'source-prefix', 'source-port-
	range', and 'source-icmp-type-range' parameters in the IANA "DOTS		range', and 'source-icmp-type-range' parameters in the IANA "DOTS
	Signal Channel CBOR Key Values" registry established by		Signal Channel CBOR Key Values" registry established by
	[I-D.ietf-dots-signal-channel] (Figure 12).		[I-D.ietf-dots-signal-channel] (Figure 13).
	The 'source-prefix', 'source-port-range', and 'source-icmp-type-		The 'source-prefix', 'source-port-range', and 'source-icmp-type-
	range' are comprehension-optional parameters.		range' are comprehension-optional parameters.
	o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys		o Note to the RFC Editor: Please delete (TBD1)-(TBD8) once CBOR keys
	are assigned from the 0x8000 - 0xBFFF range.		are assigned from the 0x8000 - 0xBFFF range.
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |		| | Type | Key | Type & | Type |
	| | | | Information | |		| | | | Information | |
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	| source-prefix | leaf-list | 0x8000 | 4 array | Array |		| source-prefix | leaf-list | 0x8000 | 4 array | Array |
	| | inet: | (TBD1) | | |		| | inet: | (TBD1) | | |
	| | ip-prefix | | 3 text string | String |		| | ip-prefix | | 3 text string | String |
	| source-port-range | list | 0x8001 | 4 array | Array |		| source-port-range | list | 0x8001 | 4 array | Array |
	| | | (TBD2) | | |		| | | (TBD2) | | |
	| source-icmp-type- | list | 0x8002 | 4 array | Array |		| source-icmp-type- | list | 0x8002 | 4 array | Array |
	| range | | (TBD3) | | |		| range | | (TBD3) | | |
	| lower-type | uint8 | 0x8003 | 0 unsigned | Number |		| lower-type | uint8 | 0x8003 | 0 unsigned | Number |
	| | | (TBD4) | | |		| | | (TBD4) | | |
	| upper-type | uint8 | 0x8004 | 0 unsigned | Number |		| upper-type | uint8 | 0x8004 | 0 unsigned | Number |
	| | | (TBD5) | | |		| | | (TBD5) | | |
			| alt-ch-client | string | 0x8005 | 3 text string | String |
			| | | (TBD6) | | |
			| alt-ch-client- | leaf-list | 0x8006 | 4 array | Array |
			| record | inet: | (TBD7) | | |
			| | ip-address| | 3 text string | String |
			| ttl | uint32 | 0x8007 | 0 unsigned | Number |
			| | | (TBD8) | | |
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	Figure 12: Assigned DOTS Signal Channel CBOR Key Values		Figure 13: Assigned DOTS Signal Channel CBOR Key Values
	4.3. New DOTS Conflict Cause		4.3. New DOTS Conflict Cause
	This document requests IANA to assign a new code from the "DOTS		This document requests IANA to assign a new code from the "DOTS
	Signal Channel Conflict Cause Codes" registry:		Signal Channel Conflict Cause Codes" registry:
	+-----+-----------------------------------+-------------+-----------+		+-----+-----------------------------------+-------------+-----------+
	| Cod | Label | Description | Reference |		| Cod | Label | Description | Reference |
	| e | | | |		| e | | | |
	+-----+-----------------------------------+-------------+-----------+		+-----+-----------------------------------+-------------+-----------+
	skipping to change at page 28, line 32 ¶		skipping to change at page 30, line 49 ¶
	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-35 (work in progress), July 2019.		ietf-dots-signal-channel-37 (work in progress), July 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 29, line 27 ¶		skipping to change at page 31, line 44 ¶
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment		Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment
	Considerations for Distributed-Denial-of-Service Open		Considerations for Distributed-Denial-of-Service Open
	Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02		Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02
	(work in progress), July 2019.		(work in progress), July 2019.
	[I-D.ietf-dots-server-discovery]		[I-D.ietf-dots-server-discovery]
	Boucadair, M. and R. K, "Distributed-Denial-of-Service		Boucadair, M. and R. K, "Distributed-Denial-of-Service
	Open Threat Signaling (DOTS) Server Discovery", draft-		Open Threat Signaling (DOTS) Agent Discovery", draft-ietf-
	ietf-dots-server-discovery-04 (work in progress), June		dots-server-discovery-05 (work in progress), August 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., Moskowitz, R., Teague, N., Xia,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Open Threat Signaling", draft-ietf-dots-use-cases-18 (work		Signaling", draft-ietf-dots-use-cases-20 (work in
	in progress), July 2019.		progress), September 2019.
	[I-D.ietf-i2nsf-terminology]		[I-D.ietf-i2nsf-terminology]
	Hares, S., Strassner, J., Lopez, D., Xia, L., and H.		Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
	Birkholz, "Interface to Network Security Functions (I2NSF)		Birkholz, "Interface to Network Security Functions (I2NSF)
	Terminology", draft-ietf-i2nsf-terminology-08 (work in		Terminology", draft-ietf-i2nsf-terminology-08 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-idr-flow-spec-v6]		[I-D.ietf-idr-flow-spec-v6]
	McPherson, D., Raszuk, R., Pithawala, B.,		McPherson, D., Raszuk, R., Pithawala, B.,
	akarch@cisco.com, a., and S. Hares, "Dissemination of Flow		akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
End of changes. 31 change blocks.
	51 lines changed or deleted		150 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/