draft-ietf-dots-signal-call-home-00.txt		draft-ietf-dots-signal-call-home-01.txt
	DOTS T. Reddy		DOTS T. Reddy
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair		Intended status: Standards Track M. Boucadair
	Expires: October 26, 2019 Orange		Expires: October 28, 2019 Orange
	J. Shallow		J. Shallow
	April 24, 2019		April 26, 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-00		draft-ietf-dots-signal-call-home-01
	Abstract		Abstract
	This document presents DOTS signal channel Call Home service, which		This document specifies the DOTS signal channel Call Home service,
	enables a DOTS server to initiate a secure connection to a DOTS		which enables a DOTS server to initiate a secure connection to a DOTS
	client, and to receive the attack traffic information from the DOTS		client, and to receive the attack traffic information from the DOTS
	client. The DOTS server in turn uses the attack traffic information		client. The DOTS server in turn uses the attack traffic information
	to identify the compromised devices launching the outgoing DDoS		to identify the compromised devices launching the outgoing DDoS
	attack and takes appropriate mitigation action.		attack and takes appropriate mitigation action(s).
	The Call Home service is not specific to the home networks; the		The Call Home service is not specific to the home networks; the
	solution targets any deployment which requires to block DDoS attack		solution targets any deployment which requires to block DDoS attack
	traffic closer to the source(s) of a DDoS attack.		traffic closer to the source(s) of a DDoS attack.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 26, 2019.		This Internet-Draft will expire on October 28, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4		1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
	2. Notational Conventions and Terminology . . . . . . . . . . . 5		2. Notational Conventions and Terminology . . . . . . . . . . . 7
	3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 5		3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7
	3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6		3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 8
	3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 6		3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 8
	3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 9		3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 12		4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 16
	4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 12		4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 16
	4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 13		4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 16
	4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 13		4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 17
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	1.1. The Problem		1.1. The Problem
	The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is		The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is
	used to carry information about a network resource or a network (or a		used to carry information about a network resource or a network (or a
	part thereof) that is under a Distributed Denial of Service (DDoS)		part thereof) that is under a Distributed Denial of Service (DDoS)
	attack. Such information is sent by a DOTS client to one or multiple		attack. Such information is sent by a DOTS client to one or multiple
	DOTS servers so that appropriate mitigation actions are undertaken on		DOTS servers so that appropriate mitigation actions are undertaken on
	traffic deemed suspicious. Various use cases are discussed in		traffic deemed suspicious. Various use cases are discussed in
	[I-D.ietf-dots-use-cases].		[I-D.ietf-dots-use-cases].
	IoT devices are becoming more and more prevalent in home networks,		Internet of Things (IoT) devices are becoming more and more prevalent
	and with compute and memory becoming cheaper and cheaper, various		in home networks, and with compute and memory becoming cheaper and
	types of IoT devices become available in the consumer market at		cheaper, various types of IoT devices become available in the
	affordable price. But on the downside, the main threat being most of		consumer market at affordable price. But on the downside, the main
	these IoT devices are bought off-the-shelf and most manufacturers		threat being most of these IoT devices are bought off-the-shelf and
	haven't considered security in the product design. IoT devices		most manufacturers haven't considered security in the product design.
	deployed in home networks can be easily compromised, they do not have		IoT devices deployed in home networks can be easily compromised, they
	an easy mechanism to upgrade, and IoT manufactures may cease		do not have an easy mechanism to upgrade, and IoT manufactures may
	manufacture and/or discontinue patching vulnerabilities on IoT		cease manufacture and/or discontinue patching vulnerabilities on IoT
	devices. However, these vulnerable and compromised devices will		devices (Sections 5.4 and 5.5 of [I-D.irtf-t2trg-iot-seccons]).
	continue be used for a long period of time in the home, and the end-		However, these vulnerable and compromised devices will continue to be
	user does not know that IoT devices in his/her home are compromised.		used for a long period of time in the home, and the end-user does not
	The compromised IoT devices are typically used for launching DDoS		know that IoT devices in his/her home are compromised. The
	attacks on the victim while the owner/administrator of the home		compromised IoT devices are typically used for launching DDoS attacks
	network is not aware about such misbehaviors. Similar to other DDoS		(Section 3 of [I-D.irtf-t2trg-iot-seccons]) on victims while the
	attacks, the victim in this attack can be an application server, a		owner/administrator of the home network is not aware about such
	host, a router, a firewall, or an entire network.		misbehaviors. Similar to other DDoS attacks, the victim in this
			attack can be an application server, a host, a router, a firewall, or
			an entire network.
	Nowadays, network devices in a home network offer network security,		Nowadays, network devices in a home network offer network security
	for instance, firewall/IPS service on a home router or gateway to		(e.g., firewall or Intrusion Protection System (IPS) service on a
	protect the devices connected to the home network from external and		home router) to protect the devices connected to the home network
	internal attacks. Over the years several techniques have been		from both external and internal attacks. Over the years several
	identified to detect DDoS attacks, some of these techniques can be		techniques have been identified to detect DDoS attacks, some of these
	enabled on home network devices but most of them are used in the		techniques can be enabled on home network devices but most of them
	Internet Service Provider (ISP)'s network. The ISP offering DDoS		are used in the Internet Service Provider (ISP)'s network. The ISP
	mitigation service can detect outgoing DDoS attack traffic		offering DDoS mitigation service can detect outgoing DDoS attack
	originating from its subscribers or the ISP may receive filtering		traffic originating from its subscribers or the ISP may receive
	rules (for example, using BGP flowspec [RFC5575]) from downstream		filtering rules (e.g., using BGP flowspec [RFC5575]) from a
	service provider to filter, block, or rate-limit DDoS attack traffic		downstream service provider to filter, block, or rate-limit DDoS
	originating from the ISP's subscribers to the downstream target.		attack traffic originating from the ISP's subscribers to a downstream
			target.
	Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris,		Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris,
	and TLS re-negotiation are difficult to detect on the home network		and Transport Layer Security (TLS) re-negotiation are difficult to
	devices without adversely affecting its performance. The reason is		detect on a home network device without adversely affecting its
	typically home routers have fast path to boost the throughput. For		performance. The reason is typically home devices such as home
	every new TCP/UDP flow, only the first few packets are punted through		routers have fast path to boost the throughput. For every new TCP/
	the slow path. Hence, it is not possible to detect various DDoS		UDP flow, only the first few packets are punted through the slow
	attacks in the slow path, since the attack payload is sent to the		path. Hence, it is not possible to detect various DDoS attacks in
	target server after the flow is switched to fast path. Deep packet		the slow path, since the attack payload is sent to the target server
	inspection (DPI) of all the packets of a flow would be able to detect		after the flow is switched to fast path. Deep Packet Inspection
	some of the attacks. However, a full-fledged DPI to detect these		(DPI) of all the packets of a flow would be able to detect some of
	type of DDoS attacks is functionally or operationally not possible		the attacks. However, a full-fledged DPI to detect these type of
	for all the devices attached to the home network owing to the memory		DDoS attacks is functionally or operationally not possible for all
	and CPU limitations of the home routers. Further, for certain DDoS		the devices attached to the home network owing to the memory and CPU
	attacks the ability to distinguish legitimate traffic from attacker		limitations of the home routers. Further, for certain DDoS attacks
	traffic on a per packet basis is complex. This complexity originates		the ability to distinguish legitimate traffic from attacker traffic
	from the fact that the packet itself may look "legitimate" and no		on a per packet basis is complex. This complexity is due to that the
	attack signature can be identified. The anomaly can be identified		packet itself may look "legitimate" and no attack signature can be
	only after detailed statistical analysis.		identified. The anomaly can be identified only after detailed
			statistical analysis.
	The ISP on the other hand can detect the DDoS attack originating from		The ISP on the other hand can detect some DDoS attacks originating
	a home network, but the ISP does not have a mechanism to detect which		from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP
	device in the home network is generating the DDoS attack traffic.		does not have a mechanism to detect which device in the home network
	The primary reason being that devices in a IPv4 Home network are		is generating the DDoS attack traffic. The primary reason being that
	typically behind a NAT border. Even in case of a IPv6 Home network,		devices in an IPv4 home network are typically behind a Network
	although the ISP can identify the infected device in the Home network		Address Translation (NAT) border. Even in case of a IPv6 home
	launching the DDoS traffic by tracking its unique IPv6 address, the		network, although the ISP can identify the infected device in the
	infected device can easily change the IP address to evade		home network launching the DDoS traffic by tracking its unique IPv6
	remediation.		address, the infected device can easily change its IPv6 address to
			evade 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 home network and ISP to the suppress the outbound DDoS attack		the network hosting an attack source and the ISP to the suppress the
	traffic originating from the home network.		outbound DDoS attack traffic originating from that network.
	1.2. The Solution		1.2. The Solution
	This specification addresses the problems discussed in Section 1.1		This specification addresses the problems discussed in Section 1.1
	and presents DOTS signal channel Call Home extension, which enables		and presents the DOTS signal channel Call Home extension, which
	the DOTS server to initiate a secure connection to the DOTS client,		enables the DOTS server to initiate a secure connection to the DOTS
	and the DOTS client then conveys the attack traffic information to		client, and the DOTS client then conveys the attack traffic
	the DOTS server.		information to the DOTS server.
			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
			source, receiving an alert from an attack target, a peer DDoS
			Mitigation System (DMS), or a transit provider). The definition of
			these triggers is deployment-specific. It is therefore out of the
			scope of this document to elaborate on how these triggers are made
			available to a DOTS client.
	In a typical deployment scenario, the DOTS server is enabled on a		In a typical deployment scenario, the DOTS server is enabled on a
	CPE, which is aligned with recent trends to enrich the CPE with		Customer Premises Equipment (CPE), which is aligned with recent
	advanced security features. Unlike classic DOTS deployments		trends to enrich the CPE with advanced security features. Unlike
	[I-D.ietf-dots-use-cases], such DOTS server maintains a single DOTS		classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS server
	signal channel session for each DOTS-capable upstream provisioning		maintains a single DOTS signal channel session for each DOTS-capable
	domain [I-D.ietf-dots-multihoming].		upstream provisioning domain [I-D.ietf-dots-multihoming].
	For instance, the DOTS server in the home network initiates the Call		For instance, the DOTS server in the home network initiates the Call
	Home in 'idle' time and then subsequently the DOTS client in the ISP		Home in 'idle' time and then subsequently the DOTS client in the ISP
	environment can initiate a mitigation request whenever the ISP		environment can initiate a mitigation request whenever the ISP
	detects there is an attack from a compromised device in the DOTS		detects there is an attack from a compromised device in the DOTS
	server domain.		server domain (i.e., from within the home network).
	The DOTS server uses the DDoS attack traffic information to identify		The DOTS server uses the DDoS attack traffic information to identify
	the compromised device in its domain launching the DDoS attack,		the compromised device in its domain that is responsible for
	notifies the network administrator, and takes appropriate mitigation		launching the DDoS attack, optionally notifies a network
	action. The mitigation action can be to quarantine the compromised		administrator, and takes appropriate mitigation action(s). A
	device or block its traffic to the attack target until the mitigation		mitigation action can be to quarantine the compromised device or
			block its traffic to the attack target(s) until the mitigation
	request is withdrawn.		request is withdrawn.
	1.3. Scope		Other motivations for introducing the Call Home function are
			discussed in Section 1.1 of [RFC8071].
			This document assumes that DOTS servers are provisioned with a way to
			know how to reach the upstream DOTS client(s), which could occur by a
			variety of means (e.g., [I-D.ietf-dots-server-discovery]). The
			specification of such means are out of scope of this document.
			1.3. Applicability Scope
	The aforementioned problems may be encountered in other deployments		The aforementioned problems may be encountered in other deployments
	than those discussed in Section 1.1. The solution specified in this		than those discussed in Section 1.1 (e.g., data centers, enterprise
	document can be used for those deployments to block DDoS attack		networks). The solution specified in this document can be used for
	traffic closer to the source(s) of the attack.		those deployments to block DDoS attack traffic closer to the
			source(s) of the attack. The Call Home reference architecture is
			shown in Figure 1.
			+-------------+
			|Attack Target|
			+-----+-------+
			| /\
			| || Target Network
			......................|.||....................
			| ||
			.--------+-||-------.
			( || )-.
			.' || '
			( Internet || )
			( || -'
			'-( || )
			'------+-||---------'
			......................|.||.....................
			| || Network Provider
			| || (DMS)
			.--------+-||-------.
			( || )-.
			.' DOTS || '
			( client || )
			( || -'
			'-( || )
			'------+-||---------'
			| ||
			......................|.||.......................
			| || Source Network
			.--------+-||-------.
			( || )-.
			.' DOTS || '
			( server || Outbound )
			( || DDoS -'
			'-( || Attack )
			'------+-||---------'
			| ||
			+-----+-++----+
			|Attack Source|
			+-------------+
			Figure 1: Call Home Reference Architecture
	It is out of the scope of this document to identify an exhaustive		It is out of the scope of this document to identify an exhaustive
	list of such deployments.		list of such deployments.
	2. Notational Conventions and Terminology		2. Notational Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The reader should be familiar with the terms defined in		The reader should be familiar with the terms defined in
	[I-D.ietf-dots-requirements].		[I-D.ietf-dots-requirements].
			The meaning of the symbols in YANG tree diagrams is defined in
			[RFC8340].
			(D)TLS is used for statements that apply to both Transport Layer
			Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
			[RFC6347]. Specific terms are used for any statement that applies to
			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 extension preserves all but one of		The DOTS signal channel Call Home extension preserves all but one of
	the DOTS client/server roles in the DOTS protocol stack, as compared		the DOTS client/server roles in the DOTS protocol stack, as compared
	to DOTS client-initiated DOTS signal channel protocol		to DOTS client-initiated DOTS signal channel protocol
	[I-D.ietf-dots-signal-channel]. The one and only role reversal that		[I-D.ietf-dots-signal-channel]. The role reversal that occurs is at
	occurs are at the TLS or DTLS layers; that is, the DOTS server acts		the (D)TLS layer; that is, (1) the DOTS server acts as a DTLS client
	as a DTLS client and the DOTS client acts as a DTLS server or the		and the DOTS client acts as a DTLS server or (2) the DOTS server acts
	DOTS server acts as a TLS client and the DOTS client acts as a TLS		as a TLS client initiating the underlying TCP connection and the DOTS
	server. The DOTS server initiates TLS handshake or DTLS handshake to		client acts as a TLS server. The DOTS server initiates (D)TLS
	the DOTS client.		handshake to the 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 DOTS server (likely, a client-domain DOTS gateway) is the TLS		with a DOTS server (likely, a client-domain DOTS gateway) is the
	server and DTLS server. However, when calling home, the DOTS server		(D)TLS server. However, when calling home, the DOTS server initially
	initially assumes the role of the TLS client and DTLS client, but the		assumes the role of the (D)TLS client, but the network element's role
	network element's role as a DOTS server remains the same.		as a DOTS server remains the same. Furthermore, existing certificate
	Furthermore, existing certificate chains and mutual authentication		chains and mutual authentication mechanisms between the DOTS agents
	mechanisms between the DOTS agents are unaffected by the Call Home		are unaffected by the Call Home function. This Call Home function
	function. This Call Home function enables the DOTS server co-located		enables the DOTS server co-located with a network element (possibly
	with a network element (possibly behind NATs and firewalls) reachable		behind NATs and firewalls) reachable by only the intended DOTS client
	by only the intended DOTS client and hence the DOTS server cannot be		and hence the DOTS server cannot be subjected to DDoS attacks.
	subjected to DDoS attacks. Other motivations for introducing the
	Call Home function are discussed in Section 1.1 of [RFC8071].
	This document assumes that DOTS servers are provisioned with a way to
	know how to reach the upstream DOTS client(s), which could occur by a
	variety of means (e.g., [I-D.ietf-dots-server-discovery]). The
	specification of such means are out of scope of this document.
	Figure 1 illustrates a sample Call Home flow exchange:		Figure 2 illustrates a sample Call Home flow exchange:
	DOTS DOTS		+--------+ +--------+
	Server Client		| DOTS | | DOTS |
			| server | | client |
			+---+----+ +----+---+
	| |		| |
	| 1. (D)TLS connection |		| 1. (D)TLS connection |
	|----------------------------------->|		|----------------------------------->|
	| 2. Mitigation request |		| 2. Mitigation request |
	|<-----------------------------------|		|<-----------------------------------|
	| |		| ... |
	Figure 1: DOTS Signal Channel Call Home Sequence Diagram		Figure 2: DOTS Signal Channel Call Home Sequence Diagram
	The Call Home procedure is as follows:		The DOTS signal channel Call Home procedure is as follows:
	1. If UDP transport is used, the DOTS server begins by initiating a		1. If UDP transport is used, the DOTS server begins by initiating a
	DTLS connection to the DOTS client. The DOTS client MUST support		DTLS connection to the DOTS client. The DOTS client MUST support
	accepting DTLS connection on the IANA-assigned port number		accepting DTLS connection on the IANA-assigned port number
	defined in Section 4.1, but MAY be configured to listen to a		defined in Section 4.1, but MAY be configured to listen to a
	different port number.		different port number.
	If TCP is used, the DOTS server begins by initiating a TCP		If TCP is used, the DOTS server begins by initiating a TCP
	connection to the DOTS client. The DOTS client MUST support		connection to the DOTS client. The DOTS client MUST support
	accepting TCP connections on the IANA-assigned port number		accepting TCP connections on the IANA-assigned port number
	skipping to change at page 6, line 50 ¶		skipping to change at page 8, line 45 ¶
	connections.		connections.
	2. Using this (D)TLS connection, the DOTS client may request,		2. Using this (D)TLS connection, the DOTS client may request,
	withdraw, or retrieve the status of mitigation requests.		withdraw, or retrieve the status of mitigation requests.
	3.2. DOTS Signal Channel Extension		3.2. DOTS Signal Channel Extension
	3.2.1. Mitigation Request		3.2.1. Mitigation Request
	This specification extends the mitigation request defined in		This specification extends the mitigation request defined in
	[I-D.ietf-dots-signal-channel] to convey the attacker source prefixes		Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the
	and source port numbers. The DOTS client conveys the following new		attacker source prefixes and source port numbers. The DOTS client
	parameters in the CBOR body of the mitigation request:		conveys the following new parameters in the CBOR body of 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
	(resp. 128) for IPv4 (resp. IPv6).		(resp. 128) for IPv4 (resp. IPv6).
	The prefix list MUST NOT include broadcast, loopback, or multicast		The prefix list MUST NOT include broadcast, loopback, or multicast
	addresses. These addresses are considered as invalid values. In		addresses. These addresses are considered as invalid values. In
	skipping to change at page 8, line 12 ¶		skipping to change at page 10, line 9 ¶
	In order to help attack source identification by a DOTS server, the		In order to help attack source identification by a DOTS server, the
	DOTS client SHOULD include in its mitigation request additional		DOTS client SHOULD include in its mitigation request additional
	information such as 'source-port-range' or 'source-icmp-type-range'.		information such as 'source-port-range' or 'source-icmp-type-range'.
	The DOTS client may not include such information if 'source-prefix'		The DOTS client may not include such information if 'source-prefix'
	conveys an IPv6 address/prefix.		conveys an IPv6 address/prefix.
	If a Carrier Grade NAT (CGN, including NAT64) is located between the		If a Carrier Grade NAT (CGN, including NAT64) is located between the
	DOTS client domain and DOTS server domain, communicating an external		DOTS client domain and DOTS server domain, communicating an external
	IP address in a mitigation request is likely to be discarded by the		IP address in a mitigation request is likely to be discarded by the
	DOTS server because the external IP address is not visible locally to		DOTS server because the external IP address is not visible locally to
	the DOTS server. The DOTS server is only aware of the internal IP		the DOTS server (see Figure 3). The DOTS server is only aware of the
	addresses/prefixes bound to its domain. Thus, the DOTS client MUST		internal IP addresses/prefixes bound to its domain. Thus, the DOTS
	NOT include the external IP address and/or port number identifying		client MUST NOT include the external IP address and/or port number
	the suspect attack source, but MUST include the internal IP address		identifying the suspect attack source, but MUST include the internal
	and/or port number. To that aim, the DOTS client SHOULD rely on		IP address and/or port number. To that aim, the DOTS client SHOULD
	mechanisms, such as [RFC8512] or [RFC8513], to retrieve the internal		rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the
	IP address and port number which are mapped to an external IP address		internal IP address and port number which are mapped to an external
	and port number.		IP address and port number.
			N | .-------------------.
			E | ( )-.
			T | .' '
			W | ( )
			O | ( DOTS server -'
			R | '-( )
			K | '-------+-----------'
			| |
			P | |
			R | +---+---+
			O | | CGN | External Realm
			V |..............|.......|......................
			I | | | Internel Realm
			D | +---+---+
			E | |
			R | |
			--- |
			.---------+---------.
			( )-.
			.' Source Network '
			( )
			( DOTS client -'
			'-( )
			'------+------------'
			|
			+-----+-------+
			|Attack Source|
			+-------------+
			Figure 3: Example of a CGN Between DOTS Domains
	If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the		If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the
	provider's domain to service its customers, the identification of an		provider's domain to service its customers, the identification of an
	attack source bound to an IPv4 address/prefix MUST also rely on		attack source bound to an IPv4 address/prefix MUST also rely on
	source port numbers because the same IPv4 address is assigned to		source port numbers because the same IPv4 address is assigned to
	multiple customers. The port information is required to		multiple customers. The port information is required to
	unambiguously identify the source of an attack.		unambiguously identify the source of an attack.
			The DOTS server MUST check that the 'source-prefix' is within the
			scope of the DOTS server domain in the Call Home scenario. Note that
			in such scenario, the DOTS server considers, by default, that any
			routeable IP prefix enclosed in 'target-prefix' is within the scope
			of the DOTS client. Invalid mitigation requests are handled as per
			Section 4.4.1 of [I-D.ietf-dots-signal-channel].
	If a translator is enabled on the boundaries of the domain hosting		If a translator is enabled on the boundaries of the domain hosting
	the DOTS server (a CPE with NAT enabled, typically), the DOTS server		the DOTS server (a CPE with NAT enabled as shown in Figure 4,
	uses the attack traffic information conveyed in a mitigation request		typically), the DOTS server uses the attack traffic information
	to find the internal source IP address of the compromised device and		conveyed in a mitigation request to find the internal source IP
	blocks the traffic from the compromised device traffic to the attack		address of the compromised device and blocks the traffic from the
	target until the mitigation request is withdrawn. Doing so allows to		compromised device traffic to the attack target until the mitigation
	isolate the suspicious device while avoiding to disturb other		request is withdrawn. Doing so allows to isolate the suspicious
	services.		device while avoiding to disturb other services.
			.-------------------.
			( )-.
			.' Network Provider '
			( (DMS) )
			( DOTS server -'
			'-( )
			'------+------------'
			|
			|
			--- +--+----+
			S | | CPE | External Realm
			O |..............|.......|................
			U | | NAT | Internel Realm
			R | +-------+
			C | |
			E | .--------+----------.
			| ( )-.
			N | .' '
			E | ( )
			T | ( DOTS client -'
			W | '-( )
			O | '------+------------'
			R | |
			K | +-----+-------+
			| |Attack Source|
			+-------------+
			Figure 4: Example of a DOTS Client Domain with a NAT Embeded in a CPE
	The DOTS server domain administrator consent MAY be required to block		The DOTS server domain administrator consent MAY be required to block
	the traffic from the compromised device to the attack target. An		the traffic from the compromised device to the attack target. An
	implementation MAY have a configuration knob to block the traffic		implementation MAY have a configuration knob to block the traffic
	from the compromised device to the attack target with or without DOTS		from the compromised device to the attack target with or without DOTS
	server domain administrator consent. If the attack traffic is		server domain administrator consent. If the attack traffic is
	blocked, the DOTS server informs the DOTS client that the attack is		blocked, the DOTS server informs the DOTS client that the attack is
	being mitigated.		being mitigated.
	If the attack traffic information is identified by the DOTS server or		If the attack traffic information is identified by the DOTS server or
	the DOTS server domain administrator as legitimate traffic, the		the DOTS server domain administrator as legitimate traffic, the
	mitigation request is rejected, and 4.09 (Conflict) is returned to		mitigation request is rejected, and 4.09 (Conflict) is returned to
	the DOTS client. The conflict-clause (defined in Section 4.4.1 of		the DOTS client. The conflict-clause (defined in Section 4.4.1 of
	[I-D.ietf-dots-signal-channel]) indicates the cause of the conflict.		[I-D.ietf-dots-signal-channel]) indicates the cause of the conflict.
	The following new value is defined:		The following new value is 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.
	If the DOTS server is co-located with a home router, it can program		Once the request is validated by the DOTS server, appropriate actions
			are enforced to block the attack traffic within the source network.
			The DOTS client is informed about the progress of the attack
			mitigation following the rules in [I-D.ietf-dots-signal-channel].
			For example, if the DOTS server is embedded in a CPE, it can program
	the packet processor to punt all the traffic from the compromised		the packet processor to punt all the traffic from the compromised
	device to the target to slow path. The home router inspects the		device to the target to slow path. The CPE inspects the punted slow
	punted slow path traffic to detect and block the outgoing DDoS attack		path traffic to detect and block the outgoing DDoS attack traffic or
	traffic or quarantine the device (e.g., using MAC level filtering)		quarantine the device (e.g., using MAC level filtering) until it is
	until it is remediated, and notifies the home administrator about the		remediated, and notifies the CPE administrator about the compromised
	compromised device.		device.
	3.2.2. DOTS Signal Call Home YANG Module		3.2.2. DOTS Signal Call Home YANG Module
	3.2.2.1. Tree Structure		3.2.2.1. Tree Structure
	This document augments the "dots-signal-channel" DOTS signal YANG		This document augments the "dots-signal-channel" DOTS signal YANG
	module defined in [I-D.ietf-dots-signal-channel] for signaling the		module defined in [I-D.ietf-dots-signal-channel] for signaling the
	attack traffic information. This document defines the YANG module		attack traffic information. This document defines the YANG module
	"ietf-dots-call-home", which has the following tree structure:		"ietf-dots-call-home", which has the following tree structure:
	module: ietf-dots-call-home		module: ietf-dots-call-home
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--rw source-prefix* inet:ip-prefix {source-signaling}?		+--rw source-prefix* inet:ip-prefix {source-signaling}?
	+--rw source-port-range*		+--rw source-port-range* [lower-port] {source-signaling}?
	| | [lower-port upper-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 upper-type] {source-signaling}?		| [lower-type] {source-signaling}?
	+--rw lower-type uint8		+--rw lower-type uint8
	+--rw upper-type uint8		+--rw upper-type? uint8
	3.2.2.2. YANG Module		3.2.2.2. YANG Module
	<CODE BEGINS> file "ietf-dots-call-home@2018-04-01.yang"		This module uses the common YANG types defined in [RFC6991].
			<CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang"
	module ietf-dots-call-home {		module ietf-dots-call-home {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
	prefix call-home;		prefix call-home;
	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 10, line 29 ¶		skipping to change at page 14, line 9 ¶
	Editor: Konda, Tirumaleswar Reddy		Editor: Konda, Tirumaleswar Reddy
	<mailto:TirumaleswarReddy_Konda@McAfee.com>;		<mailto:TirumaleswarReddy_Konda@McAfee.com>;
	Editor: Mohamed Boucadair		Editor: Mohamed Boucadair
	<mailto:mohamed.boucadair@orange.com>;		<mailto:mohamed.boucadair@orange.com>;
	Editor: Jon Shallow		Editor: Jon Shallow
	<mailto:ietf-supjps@jpshallow.com>";		<mailto:ietf-supjps@jpshallow.com>";
	description		description
	"This module contains YANG definition for the signaling		"This module contains YANG definitions for the signaling
	messages exchanged between a DOTS client and a DOTS server		messages exchanged between a DOTS client and a DOTS server
	for the call home deployment scenario.		for the Call Home deployment scenario.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2019 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	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 2018-04-01 {		revision 2019-04-25 {
	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.";
	}		}
	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 upper-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 {
	skipping to change at page 11, line 43 ¶		skipping to change at page 15, line 24 ¶
	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 upper-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.";
	skipping to change at page 15, line 24 ¶		skipping to change at page 18, line 49 ¶
	network administrator) to decide whether and which actions are		network administrator) to decide whether and which actions are
	required.		required.
	Moreover, the DOTS Call Home extension avoids misattribution by		Moreover, the DOTS Call Home extension avoids misattribution by
	appropriately identifying the network to which a suspect attack		appropriately identifying the network to which a suspect attack
	source belongs to (e.g., address sharing issues discussed in		source belongs to (e.g., address sharing issues discussed in
	Section 3.2.1).		Section 3.2.1).
	Triggers to send a DOTS mitigation request to a DOTS server are		Triggers to send a DOTS mitigation request to a DOTS server are
	deployment-specific. For example, a DOTS client may rely on the		deployment-specific. For example, a DOTS client may rely on the
	output of some DDoS detection systems deployed within the DOTS		output of some DDoS detection systems deployed within the DOTS client
	client's network to detect potential outbound DDoS attacks or on		domain to detect potential outbound DDoS attacks or on abuse claims
	abuse claims received from remote victim networks. Such DDoS		received from remote victim networks. Such DDoS detection and
	detection and mitigation techniques are not meant to track the		mitigation techniques are not meant to track the activity of users,
	activity of users, but to protect the Internet and avoid altering the		but to protect the Internet and avoid altering the IP reputation of
	IP reputation of the DOTS client's domain.		the DOTS client domain.
	7. Contributors		7. Contributors
	The following individuals have contributed to this document:		The following individuals have contributed to this document:
	Joshi Harsha		Joshi Harsha
	McAfee, Inc.		McAfee, Inc.
	Embassy Golf Link Business Park		Embassy Golf Link Business Park
	Bangalore, Karnataka 560071		Bangalore, Karnataka 560071
	India		India
	skipping to change at page 16, line 25 ¶		skipping to change at page 19, line 44 ¶
	[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>.
			[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<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,
	skipping to change at page 17, line 17 ¶		skipping to change at page 20, line 43 ¶
	of-Service Open Threat Signaling (DOTS) Server Discovery",		of-Service Open Threat Signaling (DOTS) Server Discovery",
	draft-ietf-dots-server-discovery-01 (work in progress),		draft-ietf-dots-server-discovery-01 (work in progress),
	April 2019.		April 2019.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,		Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
	Open Threat Signaling", draft-ietf-dots-use-cases-17 (work		Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
	in progress), January 2019.		in progress), January 2019.
			[I-D.irtf-t2trg-iot-seccons]
			Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
			the-Art and Challenges for the Internet of Things
			Security", draft-irtf-t2trg-iot-seccons-16 (work in
			progress), December 2018.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340,		Congestion Control Protocol (DCCP)", RFC 4340,
	DOI 10.17487/RFC4340, March 2006,		DOI 10.17487/RFC4340, March 2006,
	<https://www.rfc-editor.org/info/rfc4340>.		<https://www.rfc-editor.org/info/rfc4340>.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
	2006, <https://www.rfc-editor.org/info/rfc4632>.		2006, <https://www.rfc-editor.org/info/rfc4632>.
	skipping to change at page 18, line 15 ¶		skipping to change at page 21, line 45 ¶
	[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,		[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Murakami, T., and T. Taylor, Ed., "Mapping of Address and		Murakami, T., and T. Taylor, Ed., "Mapping of Address and
	Port with Encapsulation (MAP-E)", RFC 7597,		Port with Encapsulation (MAP-E)", RFC 7597,
	DOI 10.17487/RFC7597, July 2015,		DOI 10.17487/RFC7597, July 2015,
	<https://www.rfc-editor.org/info/rfc7597>.		<https://www.rfc-editor.org/info/rfc7597>.
	[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",		[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
	RFC 8071, DOI 10.17487/RFC8071, February 2017,		RFC 8071, DOI 10.17487/RFC8071, February 2017,
	<https://www.rfc-editor.org/info/rfc8071>.		<https://www.rfc-editor.org/info/rfc8071>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,		[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
	Vinapamula, S., and Q. Wu, "A YANG Module for Network		Vinapamula, S., and Q. Wu, "A YANG Module for Network
	Address Translation (NAT) and Network Prefix Translation		Address Translation (NAT) and Network Prefix Translation
	(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,		(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
	<https://www.rfc-editor.org/info/rfc8512>.		<https://www.rfc-editor.org/info/rfc8512>.
	[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG		[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG
	Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513,		Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513,
	DOI 10.17487/RFC8513, January 2019,		DOI 10.17487/RFC8513, January 2019,
	<https://www.rfc-editor.org/info/rfc8513>.		<https://www.rfc-editor.org/info/rfc8513>.
			[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
			Jacquenet, "An Inventory of Transport-Centric Functions
			Provided by Middleboxes: An Operator Perspective",
			RFC 8517, DOI 10.17487/RFC8517, February 2019,
			<https://www.rfc-editor.org/info/rfc8517>.
	Authors' Addresses		Authors' Addresses
	Tirumaleswar Reddy		Tirumaleswar Reddy
	McAfee, Inc.		McAfee, Inc.
	Embassy Golf Link Business Park		Embassy Golf Link Business Park
	Bangalore, Karnataka 560071		Bangalore, Karnataka 560071
	India		India
	Email: kondtir@gmail.com		Email: kondtir@gmail.com
End of changes. 52 change blocks.
	174 lines changed or deleted		338 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/