< draft-ietf-dots-multihoming-04.txt		draft-ietf-dots-multihoming-05.txt >
	Network Working Group M. Boucadair		Network Working Group M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy		Intended status: Standards Track T. Reddy
	Expires: November 30, 2020 McAfee		Expires: May 27, 2021 McAfee
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	May 29, 2020		November 23, 2020
	Multi-homing Deployment Considerations for Distributed-Denial-of-Service		Multi-homing Deployment Considerations for Distributed-Denial-of-Service
	Open Threat Signaling (DOTS)		Open Threat Signaling (DOTS)
	draft-ietf-dots-multihoming-04		draft-ietf-dots-multihoming-05
	Abstract		Abstract
	This document discusses multi-homing considerations for Distributed-		This document discusses multi-homing considerations for Distributed-
	Denial-of-Service Open Threat Signaling (DOTS). The goal is to		Denial-of-Service Open Threat Signaling (DOTS). The goal is to
	provide some guidance for DOTS clients/gateways when multihomed.		provide some guidance for DOTS clients/gateways when multihomed.
	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
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 November 30, 2020.		This Internet-Draft will expire on May 27, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	In many deployments, it may not be possible for a network to		In many deployments, it may not be possible for a network to
	determine the cause of a distributed Denial-of-Service (DoS) attack		determine the cause of a distributed Denial-of-Service (DoS) attack
	[RFC4732]. Rather, the network may just realize that some resources		[RFC4732]. Rather, the network may just realize that some resources
	seem to be under attack. To improve such situation, the IETF is		seem to be under attack. To improve such situation, the IETF is
	specifying the DDoS Open Threat Signaling (DOTS)		specifying the DDoS Open Threat Signaling (DOTS)
	[I-D.ietf-dots-architecture]architecture, where a DOTS client can		[RFC8811]architecture, where a DOTS client can inform a DOTS server
	inform a DOTS server that the network is under a potential attack and		that the network is under a potential attack and that appropriate
	that appropriate mitigation actions are required. Indeed, because		mitigation actions are required. Indeed, because the lack of a
	the lack of a common method to coordinate a real-time response among		common method to coordinate a real-time response among involved
	involved actors and network domains jeopardizes the efficiency of		actors and network domains jeopardizes the efficiency of DDoS attack
	DDoS attack mitigation actions, the DOTS protocol is meant to carry		mitigation actions, the DOTS protocol is meant to carry requests for
	requests for DDoS attack mitigation, thereby reducing the impact of		DDoS attack mitigation, thereby reducing the impact of an attack and
	an attack and leading to more efficient responsive actions.		leading to more efficient responsive actions.
	[I-D.ietf-dots-use-cases] identifies a set of scenarios for DOTS;		[I-D.ietf-dots-use-cases] identifies a set of scenarios for DOTS;
	most of these scenarios involve a Customer Premises Equipment (CPE).		most of these scenarios involve a Customer Premises Equipment (CPE).
	The high-level DOTS architecture is illustrated in Figure 1		The high-level base DOTS architecture is illustrated in Figure 1
	([I-D.ietf-dots-architecture]):		([RFC8811]):
	+-----------+ +-------------+		+-----------+ +-------------+
	| Mitigator | ~~~~~~~~~~ | DOTS Server |		| Mitigator | ~~~~~~~~~~ | DOTS Server |
	+-----------+ +-------------+		+-----------+ +-------------+
	|		|
	|		|
	|		|
	+---------------+ +-------------+		+---------------+ +-------------+
	| Attack Target | ~~~~~~ | DOTS Client |		| Attack Target | ~~~~~~ | DOTS Client |
	+---------------+ +-------------+		+---------------+ +-------------+
	Figure 1: Basic DOTS Architecture		Figure 1: Basic DOTS Architecture
	[I-D.ietf-dots-architecture] specifies that the DOTS client may be		[RFC8811] specifies that the DOTS client may be provided with a list
	provided with a list of DOTS servers; each of these servers is		of DOTS servers; each of these servers is associated with one or more
	associated with one or more IP addresses. These addresses may or may		IP addresses. These addresses may or may not be of the same address
	not be of the same address family. The DOTS client establishes one		family. The DOTS client establishes one or more DOTS sessions by
	or more DOTS sessions by connecting to the provided DOTS server(s)		connecting to the provided DOTS server(s) addresses.
	addresses.
	DOTS may be deployed within networks that are connected to one single		DOTS may be deployed within networks that are connected to one single
	upstream provider. It can also be enabled within networks that are		upstream provider. It can also be enabled within networks that are
	multi-homed. The reader may refer to [RFC3582] for an overview of		multi-homed. The reader may refer to [RFC3582] for an overview of
	multi-homing goals and motivations. This document discusses DOTS		multi-homing goals and motivations. This document discusses DOTS
	multi-homing considerations. Specifically, the document aims to:		multi-homing considerations. Specifically, the document aims to:
	1. Complete the base DOTS architecture with multi-homing specifics.		1. Complete the base DOTS architecture with multi-homing specifics.
	Those specifics need to be taken into account because:		Those specifics need to be taken into account because:
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	* One vs. multiple interconnect routers		* One vs. multiple interconnect routers
	* Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP		* Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP
	addresses		addresses
	o Describe the recommended behavior of DOTS clients and gateways for		o Describe the recommended behavior of DOTS clients and gateways for
	each case.		each case.
	Multi-homed DOTS agents are assumed to make use of the protocols		Multi-homed DOTS agents are assumed to make use of the protocols
	defined in [I-D.ietf-dots-signal-channel] and		defined in [RFC8782] and [RFC8783]; no specific extension is required
	[I-D.ietf-dots-data-channel]; no specific extension is required to		to the base DOTS protocols for deploying DOTS in a multi-homed
	the base DOTS protocols for deploying DOTS in a multi-homed context.		context.
	2. Requirements Language		2. Requirements Language
	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.
	3. Terminology		3. Terminology
	This document makes use of the terms defined in		This document makes use of the terms defined in [RFC8811] and
	[I-D.ietf-dots-architecture] and [RFC4116].		[RFC4116].
	IP indifferently refers to IPv4 or IPv6.		IP indifferently refers to IPv4 or IPv6.
	4. Multi-Homing Scenarios		4. Multi-Homing Scenarios
	This section describes some multi-homing scenarios that are relevant		This section describes some multi-homing scenarios that are relevant
	to DOTS. In the following sub-sections, only the connections of		to DOTS. In the following sub-sections, only the connections of
	border routers are shown; internal network topologies are not		border routers are shown; internal network topologies are not
	elaborated.		elaborated.
	skipping to change at page 13, line 16 ¶		skipping to change at page 13, line 16 ¶
	servers need to coordinate when a mitigation action is received		servers need to coordinate when a mitigation action is received
	from the enterprise network.		from the enterprise network.
	In both cases, DOTS agents enabled within the enterprise network MAY		In both cases, DOTS agents enabled within the enterprise network MAY
	decide to select one or all network attachments to send DOTS		decide to select one or all network attachments to send DOTS
	mitigation requests.		mitigation requests.
	6. Security Considerations		6. Security Considerations
	DOTS-related security considerations are discussed in Section 4 of		DOTS-related security considerations are discussed in Section 4 of
	[I-D.ietf-dots-architecture].		[RFC8811].
	DOTS clients should control the information that they share with peer		DOTS clients should control the information that they share with peer
	DOTS servers. For example, if a DOTS client maintains DOTS		DOTS servers. For example, if a DOTS client maintains DOTS
	associations with specific DOTS servers per interconnection link, the		associations with specific DOTS servers per interconnection link, the
	DOTS client should not leak information specific to a given link to		DOTS client should not leak information specific to a given link to
	DOTS servers not authorized to mitigate attacks received on that		DOTS servers not authorized to mitigate attacks received on that
	link. Whether this constraint is relaxed is deployment specific and		link. Whether this constraint is relaxed is deployment specific and
	must be subject to explicit consent from the DOTS client domain		must be subject to explicit consent from the DOTS client domain
	administrator.		administrator.
	skipping to change at page 13, line 42 ¶		skipping to change at page 13, line 42 ¶
	Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and		Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and
	Christian Jacquenet for sharing their comments on the mailing list.		Christian Jacquenet for sharing their comments on the mailing list.
	Thanks to Kirill Kasavchenko for the comments.		Thanks to Kirill Kasavchenko for the comments.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-dots-architecture]
	Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
	R. Compton, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-18 (work in progress), March 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>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<https://www.rfc-editor.org/info/rfc6724>.		<https://www.rfc-editor.org/info/rfc6724>.
	[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>.
	9.2. Informative References		[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
			Teague, N., and R. Compton, "DDoS Open Threat Signaling
			(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
			August 2020, <https://www.rfc-editor.org/info/rfc8811>.
	[I-D.ietf-dots-data-channel]		9.2. Informative References
	Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel
	Specification", draft-ietf-dots-data-channel-31 (work in
	progress), July 2019.
	[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-15 (work in progress),
	February 2020.		November 2020.
	[I-D.ietf-dots-signal-channel]
	Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
	N. Teague, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification", draft-
	ietf-dots-signal-channel-41 (work in progress), January
	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-21 (work in		Signaling", draft-ietf-dots-use-cases-25 (work in
	progress), May 2020.		progress), July 2020.
	[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-		[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
	Multihoming Architectures", RFC 3582,		Multihoming Architectures", RFC 3582,
	DOI 10.17487/RFC3582, August 2003,		DOI 10.17487/RFC3582, August 2003,
	<https://www.rfc-editor.org/info/rfc3582>.		<https://www.rfc-editor.org/info/rfc3582>.
	[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.		[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
	Gill, "IPv4 Multihoming Practices and Limitations",		Gill, "IPv4 Multihoming Practices and Limitations",
	RFC 4116, DOI 10.17487/RFC4116, July 2005,		RFC 4116, DOI 10.17487/RFC4116, July 2005,
	<https://www.rfc-editor.org/info/rfc4116>.		<https://www.rfc-editor.org/info/rfc4116>.
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 5 ¶
	[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain		[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
	Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,		Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
	<https://www.rfc-editor.org/info/rfc7556>.		<https://www.rfc-editor.org/info/rfc7556>.
	[RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent		[RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent
	Routing and Source Address Selection for IPv6 Hosts:		Routing and Source Address Selection for IPv6 Hosts:
	Overview of the Problem Space", RFC 8043,		Overview of the Problem Space", RFC 8043,
	DOI 10.17487/RFC8043, January 2017,		DOI 10.17487/RFC8043, January 2017,
	<https://www.rfc-editor.org/info/rfc8043>.		<https://www.rfc-editor.org/info/rfc8043>.
			[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
			Mortensen, A., and N. Teague, "Distributed Denial-of-
			Service Open Threat Signaling (DOTS) Signal Channel
			Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
			<https://www.rfc-editor.org/info/rfc8782>.
			[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
			Denial-of-Service Open Threat Signaling (DOTS) Data
			Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
			May 2020, <https://www.rfc-editor.org/info/rfc8783>.
	Authors' Addresses		Authors' Addresses
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	Rennes 35000		Rennes 35000
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Tirumaleswar Reddy		Tirumaleswar Reddy
End of changes. 16 change blocks.
	49 lines changed or deleted		45 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/