draft-ietf-dots-signal-call-home-08.txt		draft-ietf-dots-signal-call-home-09.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: September 3, 2020 Orange		Expires: March 18, 2021 Orange
	J. Shallow		J. Shallow
	March 2, 2020		September 14, 2020
	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-08		draft-ietf-dots-signal-call-home-09
	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 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	(DOTS) Signal Channel Call Home";		(DOTS) Signal Channel Call Home";
	o "| [RFCXXXX] |"		o "| [RFCXXXX] |"
	o reference: RFC XXXX		o reference: RFC XXXX
	Please update this statement with the RFC number to be assigned to		Please update this statement with the RFC number to be assigned to
	the following documents:		the following documents:
	o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling		o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
	(DOTS) Signal Channel Specification (used to be I-D.ietf-dots-		(DOTS) Signal Channel Specification" (used to be I-D.ietf-dots-
	signal-channel)		rfc8782-bis)
	Please update TBD statements with the assignment made by IANA to DOTS		Please update TBD statements with the assignment made by IANA to DOTS
	Signal Channel Call Home.		Signal Channel Call Home.
	Also, please update the "revision" date of the YANG module.		Also, please update the "revision" date of the YANG module.
	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.
	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 September 3, 2020.		This Internet-Draft will expire on March 18, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 Call Home Solution . . . . . . . . . . . . . . . . . 5
	1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6		1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
	1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8		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. DOTS Signal Channel Variations . . . . . . . . . . . . . 13		3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13
	3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13		3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13
	3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14		3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14
	3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15		3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15
	3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15		3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 28		4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 28
	4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 29		4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 29
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 29		5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	9.1. Normative References . . . . . . . . . . . . . . . . . . 31		9.1. Normative References . . . . . . . . . . . . . . . . . . 31
	9.2. Informative References . . . . . . . . . . . . . . . . . 32		9.2. Informative References . . . . . . . . . . . . . . . . . 32
	Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 35		Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	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-rfc8782-bis] is used
	used to carry information about a network resource or a network (or a		to carry information about a network resource or a network (or a part
	part thereof) that is under a Distributed Denial of Service (DDoS)		thereof) that is under a Distributed Denial of Service (DDoS) attack
	attack [RFC4732]. Such information is sent by a DOTS client to one		[RFC4732]. Such information is sent by a DOTS client to one or
	or multiple DOTS servers so that appropriate mitigation actions are		multiple DOTS servers so that appropriate mitigation actions are
	undertaken on traffic deemed suspicious. Various use cases are		undertaken on traffic deemed suspicious. Various use cases are
	discussed in [I-D.ietf-dots-use-cases].		discussed in [I-D.ietf-dots-use-cases].
	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, in particular. With compute and memory becoming		in home networks, in particular. With compute and memory becoming
	cheaper and cheaper, various types of IoT devices become available in		cheaper and cheaper, various types of IoT devices become available in
	the consumer market at affordable prices. But on the downside, the		the consumer market at affordable prices. But on the downside, the
	main threat being most of these IoT devices are bought off-the-shelf		main threat being most of these IoT devices are bought off-the-shelf
	and most manufacturers haven't considered security in the product		and most manufacturers haven't considered security in the product
	design (e.g., [Sec]). IoT devices deployed in home networks can be		design (e.g., [Sec]). IoT devices deployed in home networks can be
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	infected device can easily change its IPv6 address to evade		infected device can easily change its IPv6 address to evade
	remediation.		remediation.
	Existing approaches are still suffering from misused access network		Existing approaches are still suffering from misused access network
	resources by abusing devices; the support of means for blocking such		resources by abusing devices; the support of means for blocking such
	attacks close to the sources are missing. In particular, the DOTS		attacks close to the sources are missing. In particular, the DOTS
	signal protocol does not discuss cooperative DDoS mitigation between		signal protocol does not discuss cooperative DDoS mitigation between
	the network hosting an attack source and the ISP to the suppress the		the network hosting an attack source and the ISP to the suppress the
	outbound DDoS attack traffic originating from that network.		outbound DDoS attack traffic originating from that network.
	1.2. The Solution		1.2. The Call Home Solution
	This specification addresses the problems discussed in Section 1.1		This specification addresses the problems discussed in Section 1.1
	and presents an extension to the DOTS signal channel: DOTS signal		and presents an extension to the DOTS signal channel: DOTS signal
	channel Call Home.		channel Call Home.
	'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers		'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
	to a DOTS signal channel established at the initiative of a DOTS		to a DOTS signal channel established at the initiative of a DOTS
	server. That is, the DOTS server initiates a secure connection to a		server. That is, the DOTS server initiates a secure connection to a
	DOTS client, and uses that connection to receive the attack traffic		DOTS client, and uses that connection to receive the attack traffic
	information (e.g., attack sources) from the DOTS client. More		information (e.g., attack sources) from the DOTS client. More
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	Figure 2: DOTS Signal Channel Call Home Reference Architecture		Figure 2: DOTS Signal Channel 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.
	1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home		1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home
	The DOTS signal channel Call Home does not require nor preclude the		The DOTS signal channel Call Home does not require nor preclude the
	activation of the base DOTS signal channel		activation of the base DOTS signal channel
	[I-D.ietf-dots-signal-channel]. Some sample deployment schemes are		[I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are
	discussed in this section for illustration purposes.		discussed in this section for illustration purposes.
	The network that hosts an attack source may also be subject to		The network that hosts an attack source may also be subject to
	inbound DDoS attacks. In that case, both the base DOTS signal		inbound DDoS attacks. In that case, both the base DOTS signal
	channel and DOTS signal channel Call Home may be enabled as shown in		channel and DOTS signal channel Call Home may be enabled as shown in
	Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers).		Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers).
	DOTS Signal Channel Base DOTS		DOTS Signal Channel Base DOTS
	Call Home Signal Channel		Call Home Signal Channel
	+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+		+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The reader should be familiar with the terms defined in [RFC8612].		The reader should be familiar with the terms defined in [RFC8612].
	'Base DOTS signal channel' refers to [I-D.ietf-dots-signal-channel].		'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis].
	The meaning of the symbols in YANG tree diagrams is defined in		The meaning of the symbols in YANG tree diagrams are defined in
	[RFC8340].		[RFC8340] and [RFC8791].
	(D)TLS is used for statements that apply to both Transport Layer		(D)TLS is used for statements that apply to both Transport Layer
	Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)		Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
	[RFC6347]. Specific terms are used for any statement that applies to		[RFC6347]. Specific terms are used for any statement that applies to
	either protocol alone.		either protocol alone.
	3. DOTS Signal Channel Call Home		3. DOTS Signal Channel Call Home
	3.1. Procedure		3.1. Procedure
	The DOTS signal channel Call Home preserves all but one of the DOTS		The DOTS signal channel Call Home preserves all but one of the DOTS
	client/server roles in the DOTS protocol stack, as compared to DOTS		client/server roles in the DOTS protocol stack, as compared to DOTS
	client-initiated DOTS signal channel protocol		client-initiated DOTS signal channel protocol
	[I-D.ietf-dots-signal-channel]. The role reversal that occurs is at		[I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the
	the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a		(D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS
	DTLS client and the Call Home DOTS client acts as a DTLS server or		client and the Call Home DOTS client acts as a DTLS server or (2) the
	(2) the Call Home DOTS server acts as a TLS client initiating the		Call Home DOTS server acts as a TLS client initiating the underlying
	underlying TCP connection and the Call Home DOTS client acts as a TLS		TCP connection and the Call Home DOTS client acts as a TLS server.
	server. The Call Home DOTS server initiates (D)TLS handshake to the		The Call Home DOTS server initiates (D)TLS handshake to the Call Home
	Call Home DOTS client.		DOTS client.
	For example, a home network element (e.g., home router) co-located		For example, a home network element (e.g., home router) co-located
	with a Call Home DOTS server is the (D)TLS server. However, when		with a Call Home DOTS server is the (D)TLS server. However, when
	calling home, the DOTS server initially assumes the role of the		calling home, the DOTS server initially assumes the role of the
	(D)TLS client, but the network element's role as a DOTS server		(D)TLS client, but the network element's role as a DOTS server
	remains the same. Furthermore, existing certificate chains and		remains the same. Furthermore, existing certificate chains and
	mutual authentication mechanisms between the DOTS agents are		mutual authentication mechanisms between the DOTS agents are
	unaffected by the Call Home function. This Call Home function		unaffected by the Call Home function. This Call Home function
	enables the DOTS server co-located with a network element (possibly		enables the DOTS server co-located with a network element (possibly
	behind NATs and firewalls) reachable by only the intended Call Home		behind NATs and firewalls) reachable by only the intended Call Home
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	a specific port number, such as by explicit configuration or		a specific port number, such as by explicit configuration or
	dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such		dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such
	mutual agreement, the DOTS signal channel Call Home MUST run over		mutual agreement, the DOTS signal channel Call Home MUST run over
	port number TBD (that is, Call Home DOTS clients must support		port number TBD (that is, Call Home DOTS clients must support
	accepting DTLS (or TCP) connections on TBD) as defined in		accepting DTLS (or TCP) connections on TBD) as defined in
	Section 4.1, for both UDP and TCP. The interaction between the		Section 4.1, for both UDP and TCP. The interaction between the
	base DOTS signal channel and the Call Home is discussed in		base DOTS signal channel and the Call Home is discussed in
	Appendix A.		Appendix A.
	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] is used for initiating (D)TLS		[I-D.ietf-dots-rfc8782-bis] 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-rfc8782-bis].
	Section 3.2.1 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. DOTS Signal Channel Variations		3.2. DOTS Signal Channel Variations
	3.2.1. Heartbeat Mechanism		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-rfc8782-bis]). The Call Home DOTS server adjusts the
	the 'heartbeat-interval' to accommodate binding timers used by on-		'heartbeat-interval' to accommodate binding timers used by on-path
	path NATs and firewalls. Heartbeats will be then exchanged by the		NATs and firewalls. Heartbeats will be then exchanged by the DOTS
	DOTS agents following the instructions retrieved using the signal		agents following the instructions retrieved using the signal channel
	channel session configuration exchange.		session configuration exchange.
	It is the responsibility of Call Home DOTS servers to ensure that on-		It is the responsibility of Call Home DOTS servers to ensure that on-
	path translators/firewalls are maintaining a binding so that the same		path translators/firewalls are maintaining a binding so that the same
	external IP address and/or port number is retained for the DOTS		external IP address and/or port number is retained for the DOTS
	signal channel session. A Call Home DOTS client MAY trigger their		signal channel session. A Call Home DOTS client MAY trigger their
	heartbeat requests immediately after receiving heartbeat probes from		heartbeat requests immediately after receiving heartbeat probes from
	its peer Call Home DOTS server.		its peer Call Home DOTS server.
	When an outgoing attack that saturates the outgoing link from the		When an outgoing attack that saturates the outgoing link from the
	Call Home DOTS server is detected and reported by a Call Home DOTS		Call Home DOTS server is detected and reported by a Call Home DOTS
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 31 ¶
	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		3.2.2. Redirected Signaling
	A Call Home DOTS server MUST NOT support the Redirected Signaling		A Call Home DOTS server MUST NOT support the Redirected Signaling
	mechanism as specified in Section 4.6 of		mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]
	[I-D.ietf-dots-signal-channel] (i.e., a 5.03 response that conveys an		(i.e., a 5.03 response that conveys an alternate DOTS server's FQDN
	alternate DOTS server's FQDN or alternate DOTS server's IP		or alternate DOTS server's IP address(es)). A Call Home DOTS client
	address(es)). A Call Home DOTS client MUST silently discard such		MUST silently discard such message as only a Call Home DOTS server
	message as only a Call Home DOTS server can initiate a new (D)TLS		can initiate a new (D)TLS connection.
	connection.
	If a Call Home DOTS client wants to redirect a Call Home DOTS server		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		to another Call Home DOTS client, it MUST send a Non-confirmable PUT
	request to the predefined resource ".well-known/dots/redirect" with		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		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		PUT similar to what is described in Section 4.6 of
	[I-D.ietf-dots-signal-channel]. Furthermore, a new clause called		[I-D.ietf-dots-rfc8782-bis]. Furthermore, a new clause called 'ttl"
	'ttl" is defined to return the Time to live (TTL) of the alternate		is defined to return the Time to live (TTL) of the alternate Call
	Call Home DOTS client.		Home DOTS client.
	On receipt of this PUT request, the Call Home DOTS server responds		On receipt of this PUT request, the Call Home DOTS server responds
	with a 2.01 (Created), closes this connection and establishes a		with a 2.01 (Created), closes this connection and establishes a
	connection with the new Call Home DOTS client. The processing of the		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		TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the
	the Call Home DOTS server cannot service the PUT request, the		Call Home DOTS server cannot service the PUT request, the response is
	response is rejected with a 4.00 (bad Request).		rejected with a 4.00 (bad Request).
	Figure 8 shows a PUT request example to convey the alternate Call		Figure 8 shows a PUT request example to convey the alternate Call
	Home DOTS client 'alt-call-home-client.example' together with its IP		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		addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of
	this alternate Call Home DOTS client is 10 minutes.		this alternate Call Home DOTS client is 10 minutes.
	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: "redirect"		Uri-Path: "redirect"
	skipping to change at page 15, line 36 ¶		skipping to change at page 15, line 36 ¶
	"ietf-dots-call-home:ttl": 600		"ietf-dots-call-home:ttl": 600
	}		}
	Figure 8: Example of a PUT Request for Redirected Signaling		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-rfc8782-bis] 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:
	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].
	As a reminder, the prefix length MUST be less than or equal to 32		As a reminder, the prefix length MUST be less than or equal to 32
	(or 128) for IPv4 (or IPv6).		(or 128) for IPv4 (or IPv6).
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	Figure 9: 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-rfc8782-bis].
	Note: These validation checks do not apply when the source		Note: These validation checks do not apply when the source
	information is included as a hint in the context of the base DOTS		information is included as a hint in the context of the base DOTS
	signal channel.		signal channel.
	The Call Home DOTS server domain administrator consent MAY be		The Call Home DOTS server domain administrator consent MAY be
	required to block the traffic from the compromised device to the		required to block the traffic from the compromised device to the
	attack target. An implementation MAY have a configuration knob to		attack target. An implementation MAY have a configuration knob to
	block the traffic from the compromised device to the attack target		block the traffic from the compromised device to the attack target
	with or without DOTS server domain administrator consent. If the		with or without DOTS server domain administrator consent. If the
	attack traffic is blocked, the Call Home DOTS server informs the Call		attack traffic is blocked, the Call Home DOTS server informs the Call
	Home DOTS client that the attack is being mitigated.		Home DOTS client that the attack is being mitigated.
	If the attack traffic information is identified by the Call Home DOTS		If the attack traffic information is identified by the Call Home DOTS
	server or the Call Home DOTS server domain administrator as		server or the Call Home DOTS server domain administrator as
	legitimate traffic, the mitigation request is rejected, and 4.09		legitimate traffic, the mitigation request is rejected, and 4.09
	(Conflict) is returned to the Call Home DOTS client. The conflict-		(Conflict) is returned to the Call Home DOTS client. The conflict-
	clause (defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel])		clause (defined in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis])
	indicates the cause of the conflict. The following new value is		indicates the cause of the conflict. The following new value is
	defined:		defined:
	4: Mitigation request rejected. This code is returned by the DOTS		4: Mitigation request rejected. This code is returned by the DOTS
	server to indicate the attack traffic has been classified as		server to indicate the attack traffic has been classified as
	legitimate traffic.		legitimate traffic.
	Once the request is validated by the Call Home DOTS server,		Once the request is validated by the Call Home DOTS server,
	appropriate actions are enforced to block the attack traffic within		appropriate actions are enforced to block the attack traffic within
	the source network. The Call Home DOTS client is informed about the		the source network. The Call Home DOTS client is informed about the
	progress of the attack mitigation following the rules in		progress of the attack mitigation following the rules in
	[I-D.ietf-dots-signal-channel]. For example, if the Call Home DOTS		[I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS
	server is embedded in a CPE, it can program the packet processor to		server is embedded in a CPE, it can program the packet processor to
	punt all the traffic from the compromised device to the target to		punt all the traffic from the compromised device to the target to
	slow path. The CPE inspects the punted slow path traffic to detect		slow path. The CPE inspects the punted slow path traffic to detect
	and block the outgoing DDoS attack traffic or quarantine the device		and block the outgoing DDoS attack traffic or quarantine the device
	(e.g., using MAC level filtering) until it is remediated, and		(e.g., using MAC level filtering) until it is remediated, and
	notifies the CPE administrator about the compromised device.		notifies the CPE administrator about the compromised device.
	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-rfc8782-bis] 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 10). 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
	skipping to change at page 21, line 40 ¶		skipping to change at page 21, line 40 ¶
	+-------------+		+-------------+
	Figure 12: 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-rfc8782-bis] for signaling the
	the attack traffic information. This document defines the YANG		attack traffic information. This document defines the YANG module
	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
	/ietf-signal:mitigation-scope/ietf-signal:scope:		augment-structure /signal:dots-signal/signal:message-type
	+--rw source-prefix* inet:ip-prefix {source-signaling}?		/signal:mitigation-scope/signal:scope:
	+--rw source-port-range* [lower-port] {source-signaling}?		+-- source-prefix* inet:ip-prefix
	| +--rw lower-port inet:port-number		+-- source-port-range* [lower-port]
	| +--rw upper-port? inet:port-number		| +-- lower-port inet:port-number
	+--rw source-icmp-type-range*		| +-- upper-port? inet:port-number
	| [lower-type] {source-signaling}?		+-- source-icmp-type-range* [lower-type]
	+--rw lower-type uint8		+-- lower-type uint8
	+--rw upper-type? uint8		+-- upper-type? uint8
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment-structure /signal:dots-signal/signal:message-type
	/ietf-signal:redirected-signal:		/signal:redirected-signal:
	+--rw alt-ch-client string {call-home}?		+-- (type)?
	+--rw alt-ch-client-record* inet:ip-address {call-home}?		+--:(call-home-only)
	+--rw ttl uint32 {call-home}?		+-- alt-ch-client? string
			+-- alt-ch-client-record* inet:ip-address
			+-- ttl? uint32
	3.3.3.2. YANG/JSON Mapping Parameters to CBOR		3.3.3.2. YANG/JSON Mapping Parameters to CBOR
	The YANG/JSON mapping parameters to CBOR are listed in Table 1.		The YANG/JSON mapping parameters to CBOR are listed in Table 1.
	+--------------------+------------+------+---------------+--------+		+--------------------+------------+------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |		| | Type | Key | Type & | Type |
	| | | | Information | |		| | | | Information | |
	+--------------------+------------+------+---------------+--------+		+====================+============+======+===============+========+
	|ietf-dots-call-home:| leaf-list | | | |		|ietf-dots-call-home:| leaf-list | | | |
	| source-prefix | inet: | TBA1 | 4 array | Array |		| source-prefix | inet: | TBA1 | 4 array | Array |
	| | ip-prefix | | 3 text string | String |		| | ip-prefix | | 3 text string | String |
			+--------------------+------------+------+---------------+--------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| source-port-range | list | TBA2 | 4 array | Array |		| source-port-range | list | TBA2 | 4 array | Array |
			+--------------------+------------+------+---------------+--------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| source-icmp-type- | list | TBA3 | 4 array | Array |		| source-icmp-type- | list | TBA3 | 4 array | Array |
	| range | | | | |		| range | | | | |
	|ietf-dots-call-home:| | | | |		+--------------------+------------+------+---------------+--------+
	| lower-type | uint8 | TBA4 | 0 unsigned | Number |		| lower-type | uint8 | TBA4 | 0 unsigned | Number |
	|ietf-dots-call-home:| | | | |		+--------------------+------------+------+---------------+--------+
	| upper-type | uint8 | TBA5 | 0 unsigned | Number |		| upper-type | uint8 | TBA5 | 0 unsigned | Number |
			+--------------------+------------+------+---------------+--------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| alt-ch-client | string | TBA6 | 3 text string | String |		| alt-ch-client | string | TBA6 | 3 text string | String |
			+--------------------+------------+------+---------------+--------+
	|ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array |		|ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array |
	| alt-ch-client- | inet: | | | |		| alt-ch-client- | inet: | | | |
	| record | ip-address| | 3 text string | String |		| record | ip-address| | 3 text string | String |
			+--------------------+------------+------+---------------+--------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| ttl | uint32 | TBA8 | 0 unsigned | Number |		| ttl | uint32 | TBA8 | 0 unsigned | Number |
	+--------------------+------------+------+---------------+--------+		+--------------------+------------+------+---------------+--------+
	Table 1: YANG/JSON Mapping Parameters to CBOR		Table 1: YANG/JSON Mapping Parameters to CBOR
	3.3.3.3. YANG Module		3.3.3.3. YANG Module
	This module uses the common YANG types defined in [RFC6991].		This module uses the common YANG types defined in [RFC6991] and the
			data structure defined in [RFC8791].
	<CODE BEGINS> file "ietf-dots-call-home@2019-09-06.yang"
			<CODE BEGINS> file "ietf-dots-call-home@2020-07-07.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 dots-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";
	}		}
	import ietf-dots-signal-channel {		import ietf-dots-signal-channel {
	prefix ietf-signal;		prefix signal;
	reference		reference
	"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";
	}		}
			import ietf-yang-structure-ext {
			prefix sx;
			reference
			"RFC 8791: YANG Data Structure Extensions";
			}
	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>
	Author: Konda, Tirumaleswar Reddy		Author: Konda, Tirumaleswar Reddy
	<mailto:TirumaleswarReddy_Konda@McAfee.com>;		<mailto:TirumaleswarReddy_Konda@McAfee.com>;
	skipping to change at page 24, line 40 ¶		skipping to change at page 24, line 50 ¶
	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-09-06 {		revision 2020-07-07 {
	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";
	}		}
			sx:augment-structure "/signal:dots-signal/signal:message-type/"
	feature source-signaling {		+ "signal:mitigation-scope/signal:scope" {
	description
	"This feature means that source-related information
	can be supplied in mitigation requests. This is
	typically applicable for DOTS Call Home.";
	}
	feature call-home {
	description		description
	"This feature means that Call Home functionality		"Attacker source details.";
	is supported.";
	}
	augment "/ietf-signal:dots-signal/ietf-signal:message-type/"
	+ "ietf-signal:mitigation-scope/ietf-signal:scope" {
	if-feature source-signaling;
	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";
	description		description
	"Port range. When only lower-port is		"Port range. When only lower-port is
	present, it represents a single port number.";		present, it represents a single port number.";
	leaf lower-port {		leaf lower-port {
	type inet:port-number;		type inet:port-number;
	mandatory true;		mandatory true;
	description		description
	"Lower port number of the port range.";		"Lower port number of the port range.";
	}		}
	leaf upper-port {		leaf upper-port {
	type inet:port-number;		type inet:port-number;
	must ". >= ../lower-port" {		must '. >= ../lower-port' {
	error-message		error-message
	"The upper port number must be greater than		"The upper port number must be greater than
	or equal to lower port number.";		or equal to lower port number.";
	}		}
	description		description
	"Upper port number of the port range.";		"Upper port number of the port range.";
	}		}
	}		}
	list source-icmp-type-range {		list source-icmp-type-range {
	key "lower-type";		key "lower-type";
	description		description
	"ICMP type range. When only lower-type is		"ICMP type range. When only lower-type is
	present, it represents a single ICMP type.";		present, it represents a single ICMP type.";
	leaf lower-type {		leaf lower-type {
	type uint8;		type uint8;
	mandatory true;		mandatory true;
	description		description
	"Lower ICMP type of the ICMP type range.";		"Lower ICMP type of the ICMP type range.";
	}		}
	leaf upper-type {		leaf upper-type {
	type uint8;		type uint8;
	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.";
	}		}
	}		}
	}		}
			sx:augment-structure "/signal:dots-signal/signal:message-type/"
	augment "/ietf-signal:dots-signal/ietf-signal:message-type/"		+ "signal:redirected-signal" {
	+ "ietf-signal:redirected-signal" {
	if-feature call-home;
	description		description
	"The alternate Call Home DOTS client.";		"The alternate Call Home DOTS client.";
			choice type {
	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		description
	"The Time to live (TTL) of the alternate Call Home		"Indicates the type of the DOTS session.";
	DOTS client.";		case call-home-only {
			description
			"These attributes appear only in a call home signal
			channel message from the Call Home DOTS client
			to the Call Home DOTS server.";
			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" [ServicePorts].
	https://www.iana.org/assignments/service-names-port-numbers/service-
	names-port-numbers.xhtml.
	Service Name: dots-call-home		Service Name: dots-call-home
	Port Number: TBD		Port Number: TBD
	Transport Protocol(s): TCP/UDP		Transport Protocol(s): TCP/UDP
	Description: DOTS Signal Channel Call Home		Description: DOTS Signal Channel Call Home
	Assignee: IESG <iesg@ietf.org>		Assignee: IESG <iesg@ietf.org>
	Contact: IETF Chair <chair@ietf.org>		Contact: IETF Chair <chair@ietf.org>
	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 following comprehension-optional		This specification registers the following comprehension-optional
	parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key		parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key
	Values" registry established by [I-D.ietf-dots-signal-channel] and		Values" registry [Key-Map].
	maintained at https://www.iana.org/assignments/dots/dots.xhtml#dots-
	signal-channel-cbor-key-values.
	o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are		o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are
	assigned from the 32768-49151 range.		assigned from the 32768-49151 range.
	+--------------------+-------+-------+------------+---------------+		+--------------------+-------+-------+------------+---------------+
	| Parameter Name | CBOR | CBOR | Change | Specification |		| Parameter Name | CBOR | CBOR | Change | Specification |
	| | Key | Major | Controller | Document(s) |		| | Key | Major | Controller | Document(s) |
	| | Value | Type | | |		| | Value | Type | | |
	+--------------------+-------+-------+------------+---------------+		+====================+=======+=======+============+===============+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| source-prefix | TBA1 | 4 | IESG | [RFCXXXX] |		| source-prefix | TBA1 | 4 | IESG | [RFCXXXX] |
			+--------------------+-------+-------+------------+---------------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| source-port-range | TBA2 | 4 | IESG | [RFCXXXX] |		| source-port-range | TBA2 | 4 | IESG | [RFCXXXX] |
			+--------------------+-------+-------+------------+---------------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] |		| source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] |
	| range | | | | |		| range | | | | |
	|ietf-dots-call-home:| | | | |		+--------------------+-------+-------+------------+---------------+
	| lower-type | TBA4 | 0 | IESG | [RFCXXXX] |		| lower-type | TBA4 | 0 | IESG | [RFCXXXX] |
	|ietf-dots-call-home:| | | | |		+--------------------+-------+-------+------------+---------------+
	| upper-type | TBA5 | 0 | IESG | [RFCXXXX] |		| upper-type | TBA5 | 0 | IESG | [RFCXXXX] |
			+--------------------+-------+-------+------------+---------------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] |		| alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] |
			+--------------------+-------+-------+------------+---------------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	|alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] |		|alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] |
			+--------------------+-------+-------+------------+---------------+
	|ietf-dots-call-home:| | | | |		|ietf-dots-call-home:| | | | |
	| ttl | TBA8 | 0 | IESG | [RFCXXXX] |		| ttl | TBA8 | 0 | IESG | [RFCXXXX] |
	+--------------------+-------+-------+------------+---------------+		+--------------------+-------+-------+------------+---------------+
	Table 2: Assigned DOTS Signal Channel CBOR Key Values		Table 2: 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 established by		Signal Channel Conflict Cause Codes" registry [Cause].
	[I-D.ietf-dots-signal-channel] and maintained at
	https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
	conflict-cause-codes.
	+-------+----------------------------------+------------+-----------+		+-------+----------------------------------+------------+-----------+
	| Code | Label | Descriptio | Reference |		| Code | Label | Descriptio | Reference |
	| | | n | |		| | | n | |
	+-------+----------------------------------+------------+-----------+		+-------+----------------------------------+------------+-----------+
	| 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] |		| 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] |
	| A9) | traffic | request | |		| A9) | traffic | request | |
	| | | rejected. | |		| | | rejected. | |
	| | | This code | |		| | | This code | |
	| | | is | |		| | | is | |
	skipping to change at page 29, line 38 ¶		skipping to change at page 29, line 38 ¶
	4.4. DOTS Signal Call Home YANG Module		4.4. DOTS Signal Call Home YANG Module
	This document requests IANA to register the following URI in the "ns"		This document requests IANA to register the following URI in the "ns"
	subregistry within the "IETF XML Registry" [RFC3688]:		subregistry within the "IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home		URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	This document requests IANA to register the following YANG module in		This document requests IANA to register the following YANG module in
	the "YANG Module Names" subregistry [RFC7950] within the "YANG		the "YANG Module Names" subregistry [RFC6020] within the "YANG
	Parameters" registry:		Parameters" registry:
	name: ietf-dots-call-home		name: ietf-dots-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: dots-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 (D)TLS connection. DOTS signal		having the DOTS server initiate the (D)TLS connection. DOTS signal
	channel related security considerations discussed in Section 10 of		channel related security considerations discussed in Section 11 of
	[I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST		[I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST
	authenticate each other using (D)TLS before a DOTS signal channel		authenticate each other using (D)TLS before a DOTS 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
	skipping to change at page 32, line 5 ¶		skipping to change at page 31, line 47 ¶
	8. Acknowledgements		8. Acknowledgements
	Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema		Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema
	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-rfc8782-bis]
	Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and		Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed
	N. Teague, "Distributed Denial-of-Service Open Threat		Denial-of-Service Open Threat Signaling (DOTS) Signal
	Signaling (DOTS) Signal Channel Specification", draft-		Channel Specification", draft-ietf-dots-rfc8782-bis-00
	ietf-dots-signal-channel-41 (work in progress), January		(work in progress), August 2020.
	2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	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>.
			[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
			the Network Configuration Protocol (NETCONF)", RFC 6020,
			DOI 10.17487/RFC6020, October 2010,
			<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data
			Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
			June 2020, <https://www.rfc-editor.org/info/rfc8791>.
	9.2. Informative References		9.2. Informative References
			[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
			<https://www.iana.org/assignments/dots/dots.xhtml#dots-
			signal-channel-conflict-cause-codes>.
	[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-03 (work in progress), January 2020.		multihoming-04 (work in progress), May 2020.
	[I-D.ietf-dots-server-discovery]		[I-D.ietf-dots-server-discovery]
	Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-		Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
	Service Open Threat Signaling (DOTS) Agent Discovery",		Service Open Threat Signaling (DOTS) Agent Discovery",
	draft-ietf-dots-server-discovery-10 (work in progress),		draft-ietf-dots-server-discovery-10 (work in progress),
	February 2020.		February 2020.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	L., and K. Nishizuka, "Use cases for DDoS Open Threat		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Signaling", draft-ietf-dots-use-cases-20 (work in		Signaling", draft-ietf-dots-use-cases-25 (work in
	progress), September 2019.		progress), July 2020.
	[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]
	Loibl, C., Raszuk, R., and S. Hares, "Dissemination of		Loibl, C., Raszuk, R., and S. Hares, "Dissemination of
	Flow Specification Rules for IPv6", draft-ietf-idr-flow-		Flow Specification Rules for IPv6", draft-ietf-idr-flow-
	spec-v6-10 (work in progress), November 2019.		spec-v6-14 (work in progress), August 2020.
			[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
			<https://www.iana.org/assignments/dots/dots.xhtml#dots-
			signal-channel-cbor-key-values>.
	[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address		[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
	Translator (NAT) Terminology and Considerations",		Translator (NAT) Terminology and Considerations",
	RFC 2663, DOI 10.17487/RFC2663, August 1999,		RFC 2663, DOI 10.17487/RFC2663, August 1999,
	<https://www.rfc-editor.org/info/rfc2663>.		<https://www.rfc-editor.org/info/rfc2663>.
	[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>.
	skipping to change at page 35, line 27 ¶		skipping to change at page 35, line 32 ¶
	Threat Signaling (DOTS) Requirements", RFC 8612,		Threat Signaling (DOTS) Requirements", RFC 8612,
	DOI 10.17487/RFC8612, May 2019,		DOI 10.17487/RFC8612, May 2019,
	<https://www.rfc-editor.org/info/rfc8612>.		<https://www.rfc-editor.org/info/rfc8612>.
	[Sec] UK Department for Digital Culture, Media & Sport, "Secure		[Sec] UK Department for Digital Culture, Media & Sport, "Secure
	by Design: Improving the cyber security of consumer		by Design: Improving the cyber security of consumer
	Internet of Things Report", March 2018,		Internet of Things Report", March 2018,
	<https://www.gov.uk/government/publications/secure-by-		<https://www.gov.uk/government/publications/secure-by-
	design-report>.		design-report>.
			[ServicePorts]
			IANA, "Service Name and Transport Protocol Port Number
			Registry", <https://www.iana.org/assignments/service-
			names-port-numbers/service-names-port-numbers.xhtml>.
	Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home		Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home
	With the DOTS signal channel Call Home, there is a chance that two		With the DOTS signal channel Call Home, there is a chance that two
	DOTS agents can simultaneously establish two DOTS signal channels		DOTS agents can simultaneously establish two DOTS signal channels
	with different directions (base DOTS signal channel and DOTS signal		with different directions (base DOTS signal channel and DOTS signal
	channel Call Home). Here is one example drawn from the home network.		channel Call Home). Here is one example drawn from the home network.
	Nevertheless, the outcome of the discussion is not specific to these		Nevertheless, the outcome of the discussion is not specific to these
	networks, but applies to any DOTS Call Home scenario.		networks, but applies to any DOTS Call Home scenario.
	In the Call Home scenario, the DOTS server in, for example, the home		In the Call Home scenario, the DOTS server in, for example, the home
	skipping to change at page 36, line 7 ¶		skipping to change at page 36, line 16 ¶
	peer at the same time the home network element will have the base		peer at the same time the home network element will have the base
	DOTS signal channel and the DOTS signal channel Call Home defined in		DOTS signal channel and the DOTS signal channel Call Home defined in
	this specification. Thus, these two signal channels need to be		this specification. Thus, these two signal channels need to be
	distinguished when they are both supported. Two approaches have been		distinguished when they are both supported. Two approaches have been
	considered for distinguishing the two DOTS signal channels, but only		considered for distinguishing the two DOTS signal channels, but only
	the one that using the dedicated port number has been chosen as the		the one that using the dedicated port number has been chosen as the
	best choice.		best choice.
	By using a dedicated port number for each, these two signal channels		By using a dedicated port number for each, these two signal channels
	can be separated unambiguously and easily. For example, the CPE uses		can be separated unambiguously and easily. For example, the CPE uses
	the port number 4646 allocated in [I-D.ietf-dots-signal-channel] to		the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to
	initiate the basic signal channel to the ISP when it acts as the DOTS		initiate the basic signal channel to the ISP when it acts as the DOTS
	client, and uses the port number TBD to initiate the signal channel		client, and uses the port number TBD to initiate the signal channel
	Call Home. Based on the different port numbers, the ISP can directly		Call Home. Based on the different port numbers, the ISP can directly
	decide which kind of procedures should follow immediately after it		decide which kind of procedures should follow immediately after it
	receives the DOTS messages. This approach just requires two (D)TLS		receives the DOTS messages. This approach just requires two (D)TLS
	sessions to be established respectively for the basic signal channel		sessions to be established respectively for the basic signal channel
	and signal channel Call Home.		and signal channel Call Home.
	The other approach is signaling the role of each DOTS agent (e.g., by		The other approach is signaling the role of each DOTS agent (e.g., by
	using the DOTS data channel). For example, the DOTS agent in the		using the DOTS data channel). For example, the DOTS agent in the
End of changes. 73 change blocks.
	153 lines changed or deleted		174 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/