< draft-ietf-dots-multihoming-11.txt		draft-ietf-dots-multihoming-12.txt >
	Network Working Group M. Boucadair		Network Working Group M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Informational T. Reddy.K		Intended status: Informational T. Reddy.K
	Expires: 14 August 2022 Akamai		Expires: 23 October 2022 Akamai
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	10 February 2022		21 April 2022
	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-11		draft-ietf-dots-multihoming-12
	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 and client-domain DOTS		provide some guidance for DOTS clients and client-domain DOTS
	gateways when multihomed.		gateways when multihomed.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 14 August 2022.		This Internet-Draft will expire on 23 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7		4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7
	5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8		5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8
	5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8		5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream		5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 14		5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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
	appear to be under attack. To help with such situations, the IETF		appear to be under attack. To help with such situations, the IETF
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	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:
	* Sending a DOTS mitigation request to an arbitrary DOTS server		* Sending a DOTS mitigation request to an arbitrary DOTS server
	will not necessarily help in mitigating a DDoS attack.		will not necessarily help in mitigating a DDoS attack.
	* Blindly forking all DOTS mitigation requests among all		* Randomly replicating all DOTS mitigation requests among all
	available DOTS servers is suboptimal.		available DOTS servers is suboptimal.
	* Sequentially contacting DOTS servers may increase the delay		* Sequentially contacting DOTS servers may increase the delay
	before a mitigation plan is enforced.		before a mitigation plan is enforced.
	2. Identify DOTS deployment schemes in a multi-homing context, where		2. Identify DOTS deployment schemes in a multi-homing context, where
	DOTS services can be offered by all or a subset of upstream		DOTS services can be offered by all or a subset of upstream
	providers.		providers.
	3. Provide guidelines and recommendations for placing DOTS requests		3. Provide guidelines and recommendations for placing DOTS requests
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	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 [RFC9132] and [RFC8783]. This document does not require		defined in [RFC9132] and [RFC8783]. This document does not require
	any specific extension to the base DOTS protocols for deploying DOTS		any specific extension to the base DOTS protocols for deploying DOTS
	in a multi-homed context.		in a multi-homed 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 [RFC8811] and		This document makes use of the terms defined in [RFC8811], [RFC8612],
	[RFC4116]. In particular:		and [RFC4116]. In particular:
	Provider-Aggregatable (PA) addresses: are globally-unique addresses		Provider-Aggregatable (PA) addresses: are globally-unique addresses
	assigned by a transit provider to a customer. The addresses are		assigned by a transit provider to a customer. The addresses are
	considered "aggregatable" because the set of routes corresponding		considered "aggregatable" because the set of routes corresponding
	to the PA addresses are usually covered by an aggregate route set		to the PA addresses are usually covered by an aggregate route set
	corresponding to the address space operated by the transit		corresponding to the address space operated by the transit
	provider, from which the assignment was made (Section 2 of		provider, from which the assignment was made (Section 2 of
	[RFC4116]).		[RFC4116]).
	Provider-Independent (PI) addresses: are globally-unique addresses		Provider-Independent (PI) addresses: are globally-unique addresses
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	managed by distinct administrative entities).		managed by distinct administrative entities).
	Unlike the previous scenario, two sub-cases can be considered for an		Unlike the previous scenario, two sub-cases can be considered for an
	enterprise network with regards to assigned addresses:		enterprise network with regards to assigned addresses:
	1. PI addresses/prefixes: The enterprise is the owner of the IP		1. PI addresses/prefixes: The enterprise is the owner of the IP
	addresses/prefixes; the same address/prefix is then used when		addresses/prefixes; the same address/prefix is then used when
	establishing communications over any of the provisioning domains.		establishing communications over any of the provisioning domains.
	2. PA addresses/prefixes: Each of the provisioning domains assigns		2. PA addresses/prefixes: Each of the provisioning domains assigns
	IP addresses/prefixes to the enterprise network.		IP addresses/prefixes to the enterprise network. These
			addresses/prefixes are used when communicating over the
			provisioning domain that assigned them.
	+------+ +------+		+------+ +------+
	| ISP1 | | ISP2 |		| ISP1 | | ISP2 |
	+---+--+ +--+---+		+---+--+ +--+---+
	| | Service Providers		| | Service Providers
	............|....................|.......................		............|....................|.......................
	+---------++---------+ Enterprise Network		+---------++---------+ Enterprise Network
	||		||
	+--++-+		+--++-+
	| CPE |		| CPE |
	+-----+		+-----+
	... (Internal Network)		... (Internal Network)
	Figure 3: Multi-homed Enterprise Network (Single CPE connected to		Figure 3: Multi-homed Enterprise Network (Single CPE connected to
	Multiple Networks)		Multiple Networks)
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	This scenario is similar to the one described in Section 4.2; the		This scenario is similar to the one described in Section 4.2; the
	main difference is that dedicated routers (rtr1 and rtr2) are used to		main difference is that dedicated routers (CPE1 and CPE2) are used to
	connect to each provisioning domain.		connect to each provisioning domain.
	+------+ +------+		+------+ +------+
	| ISP1 | | ISP2 |		| ISP1 | | ISP2 |
	+---+--+ +--+---+		+---+--+ +--+---+
	| | Service Providers		| | Service Providers
	......................|..........|.......................		......................|..........|.......................
	| | Enterprise Network		| | Enterprise Network
	+---+--+ +--+---+		+---+--+ +--+---+
	| rtr1 | | rtr2 |		| CPE1 | | CPE2 |
	+------+ +------+		+------+ +------+
	... (Internal Network)		... (Internal Network)
	Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple		Figure 4: Multi-homed Enterprise Network (Multiple CPEs, Multiple
	ISPs)		ISPs)
	4.4. Multi-homed Enterprise with the Same ISP		4.4. Multi-homed Enterprise with the Same ISP
	This scenario is a variant of Section 4.2 and Section 4.3 in which		This scenario is a variant of Sections 4.2 and 4.3 in which multi-
	multi-homing is supported by the same ISP (i.e., same provisioning		homing is supported by the same ISP (i.e., same provisioning domain).
	domain).
	5. DOTS Multi-homing Deployment Considerations		5. DOTS Multi-homing Deployment Considerations
	Table 1 provides some sample, non-exhaustive, deployment schemes to		Table 1 provides some sample, non-exhaustive, deployment schemes to
	illustrate how DOTS agents may be deployed for each of the scenarios		illustrate how DOTS agents may be deployed for each of the scenarios
	introduced in Section 4.		introduced in Section 4.
	+=========================+=======================+===============+		+=========================+=======================+===============+
	| Scenario | DOTS client | Client-domain |		| Scenario | DOTS client | Client-domain |
	| | | DOTS gateway |		| | | DOTS gateway |
	+=========================+=======================+===============+		+=========================+=======================+===============+
	| Residential CPE | CPE | N/A |		| Residential CPE | CPE | N/A |
	+-------------------------+-----------------------+---------------+		+-------------------------+-----------------------+---------------+
	| Single CPE, Multiple | Internal hosts or CPE | CPE |		| Single CPE, Multiple | Internal hosts or CPE | CPE |
	| provisioning domains | | |		| provisioning domains | | |
	+-------------------------+-----------------------+---------------+		+-------------------------+-----------------------+---------------+
	| Multiple CPEs, Multiple | Internal hosts or all | CPEs (rtr1 |		| Multiple CPEs, Multiple | Internal hosts or all | CPEs (CPE1 |
	| provisioning domains | CPEs (rtr1 and rtr2) | and rtr2) |		| provisioning domains | CPEs (CPE1 and CPE2) | and CPE2) |
	+-------------------------+-----------------------+---------------+		+-------------------------+-----------------------+---------------+
	| Multi-homed enterprise, | Internal hosts or all | CPEs (rtr1 |		| Multi-homed enterprise, | Internal hosts or all | CPEs (CPE1 |
	| Single provisioning | CPEs (rtr1 and rtr2) | and rtr2) |		| Single provisioning | CPEs (CPE1 and CPE2) | and CPE2) |
	| domain | | |		| domain | | |
	+-------------------------+-----------------------+---------------+		+-------------------------+-----------------------+---------------+
	Table 1: Sample Deployment Cases		Table 1: Sample Deployment Cases
	These deployment schemes are further discussed in the following		These deployment schemes are further discussed in the following
	subsections.		subsections.
	5.1. Residential CPE		5.1. Residential CPE
	Figure 5 depicts DOTS sessions that need to be established between a		Figure 5 depicts DOTS sessions that need to be established between a
	DOTS client (C) and two DOTS servers (S1, S2) within the context of		DOTS client (C) and two DOTS servers (S1, S2) within the context of
	the scenario described in Section 4.1. As listed in Table 1, the		the scenario described in Section 4.1. As listed in Table 1, the
	DOTS client is hosted by the residential CPE.		DOTS client is hosted by the residential CPE.
			+--+
			----------|S1|
			/ +--+
			/ DOTS Server Domain #1
			/
			+---+/
			| C |
			+---+\
			CPE \
			\
			\ +--+
			----------|S2|
			+--+
			DOTS Server Domain #2
			Figure 5: DOTS Associations for a Multihomed Residential CPE
	The DOTS client MUST resolve the DOTS server's name provided by each		The DOTS client MUST resolve the DOTS server's name provided by each
	provisioning domain using either the DNS servers learned from the		provisioning domain using either the DNS servers learned from the
	respective provisioning domain or from the DNS servers associated		respective provisioning domain or from the DNS servers associated
	with the interface(s) for which a DOTS server was explicitly		with the interface(s) for which a DOTS server was explicitly
	configured (Section 4). IPv6-capable DOTS clients MUST use the		configured (Section 4). IPv6-capable DOTS clients MUST use the
	source address selection algorithm defined in [RFC6724] to select the		source address selection algorithm defined in [RFC6724] to select the
	candidate source addresses to contact each of these DOTS servers.		candidate source addresses to contact each of these DOTS servers.
	DOTS sessions MUST be established and MUST be maintained with each of		DOTS sessions MUST be established and MUST be maintained with each of
	the DOTS servers because the mitigation scope of each of these		the DOTS servers because the mitigation scope of each of these
	servers is restricted. The DOTS client SHOULD use the certificate		servers is restricted. The DOTS client MUST use the security
	provided by a provisioning domain to authenticate itself to the DOTS		credentials (a certificate, typically) provided by a provisioning
	server(s) provided by the same provisioning domain. How such a		domain to authenticate itself to the DOTS server(s) provided by the
	certificate is provided to the DOTS client is out of the scope of		same provisioning domain. How such security credentials are provided
	this document.		to the DOTS client is out of the scope of this document. The reader
			may refer to Section 7.1 of [RFC9132] for more details about DOTS
			authentication methods.
	When conveying a mitigation request to protect the attack target(s),		When conveying a mitigation request to protect the attack target(s),
	the DOTS client MUST select an available DOTS server whose network		the DOTS client MUST select an available DOTS server whose network
	has assigned the IP prefixes from which target prefixes/addresses are		has assigned the IP prefixes from which target prefixes/addresses are
	derived. This implies that if no appropriate DOTS server is found,		derived. This implies that if no appropriate DOTS server is found,
	the DOTS client MUST NOT send the mitigation request to any other		the DOTS client MUST NOT send the mitigation request to any other
	available DOTS server.		available DOTS server.
	For example, a mitigation request to protect target resources bound		For example, a mitigation request to protect target resources bound
	to a PA IP address/prefix cannot be satisfied by a provisioning		to a PA IP address/prefix cannot be satisfied by a provisioning
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 18 ¶
	with S2 using Protocol Configuration Option (PCO) [TS.24008] when		with S2 using Protocol Configuration Option (PCO) [TS.24008] when
	attaching to a second network, the DOTS client must record the		attaching to a second network, the DOTS client must record the
	interface from which a DOTS server was provisioned. DOTS signaling		interface from which a DOTS server was provisioned. DOTS signaling
	session to a given DOTS server must be established using the		session to a given DOTS server must be established using the
	interface from which the DOTS server was provisioned. If a DOTS		interface from which the DOTS server was provisioned. If a DOTS
	server is explicitly configured, DOTS signaling with that server must		server is explicitly configured, DOTS signaling with that server must
	be established via the interfaces that are indicated in the explicit		be established via the interfaces that are indicated in the explicit
	configuration or via any active interface if no interface is		configuration or via any active interface if no interface is
	configured.		configured.
	+--+
	----------|S1|
	/ +--+
	/ DOTS Server Domain #1
	/
	+---+/
	| C |
	+---+\
	CPE \
	\
	\ +--+
	----------|S2|
	+--+
	DOTS Server Domain #2
	Figure 5: DOTS Associations for a Multihomed Residential CPE
	5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs		5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs
	Figure 6 illustrates the DOTS sessions that can be established with a		Figure 6 illustrates the DOTS sessions that can be established with a
	client-domain DOTS gateway (hosted within the CPE as per Table 1),		client-domain DOTS gateway (hosted within the CPE as per Table 1),
	which is enabled within the context of the scenario described in		which is enabled within the context of the scenario described in
	Section 4.2. This deployment is characterized as follows:		Section 4.2. This deployment is characterized as follows:
	* One of more DOTS clients are enabled in hosts located in the		* One of more DOTS clients are enabled in hosts located in the
	internal network.		internal network.
	* A client-domain DOTS gateway is enabled to aggregate and then		* A client-domain DOTS gateway is enabled to aggregate and then
	relay the requests towards upstream DOTS servers.		relay the requests towards upstream DOTS servers.
			+--+
			.................... ----------|S1|
			. +---+ . / +--+
			. | C1|----+ ./ DOTS Server Domain #1
			. +---+ | .
			. | /.
			.+---+ +-+-+/ .
			.| C3|------| G | .
			.+---+ +-+-+\ .
			. CPE \.
			. +---+ | .
			. | C2|----+ .\
			. +---+ . \ +--+
			'..................' ----------|S2|
	+--+		+--+
	----------|S1|		DOTS Client Domain DOTS Server Domain #2
	+---+ / +--+
	| C1|----+ / DOTS Server Domain #1
	+---+ | /
	| /
	+---+ +-+-+/
	| C3|------| G |
	+---+ +-+-+\
	CPE \
	+---+ | \
	| C2|----+ \
	+---+ \ +--+
	----------|S2|
	+--+
	DOTS Server Domain #2
	Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple		Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple
	DOTS Servers		DOTS Servers
	When PA addresses/prefixes are in use, the same considerations		When PA addresses/prefixes are in use, the same considerations
	discussed in Section 5.1 need to be followed by the client-domain		discussed in Section 5.1 need to be followed by the client-domain
	DOTS gateway to contact its DOTS server(s). The client-domain DOTS		DOTS gateway to contact its DOTS server(s). The client-domain DOTS
	gateways can be reachable from DOTS clients by using an unicast		gateways can be reachable from DOTS clients by using an unicast
	address or an anycast address (Section 3.2.4 of [RFC8811]).		address or an anycast address (Section 3.2.4 of [RFC8811]).
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 38 ¶
	+--------|C1|--------+		+--------|C1|--------+
	| . +--+ . |		| . +--+ . |
	| . . |		| . . |
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	|S2|------|C3|------|S1|		|S2|------|C3|------|S1|
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	| . . |		| . . |
	| . +--+ . |		| . +--+ . |
	+--------|C2|--------+		+--------|C2|--------+
	. +--+ .		. +--+ .
	..........		'........'
	DOTS Client		DOTS Client
	Domain		Domain
	Figure 7: Multiple DOTS Clients, Multiple DOTS Servers		Figure 7: Multiple DOTS Clients, Multiple DOTS Servers
	If PI addresses/prefixes are in use, the DOTS client MUST send a		If PI addresses/prefixes are in use, the DOTS client MUST send a
	mitigation request to all the DOTS servers. The use of anycast		mitigation request to all the DOTS servers. The use of anycast
	addresses to reach these DOTS servers is NOT RECOMMENDED. If a well-		addresses to reach these DOTS servers is NOT RECOMMENDED. If a well-
	known anycast address is used to reach multiple DOTS servers, the CPE		known anycast address is used to reach multiple DOTS servers, the CPE
	may not be able to select the appropriate provisioning domain to		may not be able to select the appropriate provisioning domain to
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 24 ¶
	them is responsible for handling communications with a specific DOTS		them is responsible for handling communications with a specific DOTS
	server (see Figure 8).		server (see Figure 8).
	..........		..........
	. +--+ .		. +--+ .
	+--------|C1| .		+--------|C1| .
	| . +--+ .		| . +--+ .
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	|S2| . |C2|------|S1|		|S2| . |C2|------|S1|
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	..........		'........'
	DOTS Client		DOTS Client
	Domain		Domain
	Figure 8: Single Homed DOTS Clients		Figure 8: Single Homed DOTS Clients
	For both deployments depicted in Figures 7 and 8, each DOTS client		For both deployments depicted in Figures 7 and 8, each DOTS client
	SHOULD be provided with policies (e.g., a prefix filter that will be		SHOULD be provided with policies (e.g., a prefix filter that is used
	against DDoS detection alarms) that will trigger DOTS communications		to filter DDoS detection alarms) that will trigger DOTS
	with the DOTS servers. Such policies will help the DOTS client to		communications with the DOTS servers. Such policies will help the
	select the appropriate destination DOTS server. The CPE MUST select		DOTS client to select the appropriate destination DOTS server. The
	the appropriate source IP address when forwarding DOTS messages		CPE MUST select the appropriate source IP address when forwarding
	received from an internal DOTS client.		DOTS messages received from an internal DOTS client.
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	The deployments depicted in Figures 7 and 8 also apply to the		The deployments depicted in Figures 7 and 8 also apply to the
	scenario described in Section 4.3. One specific problem for this		scenario described in Section 4.3. One specific problem for this
	scenario is to select the appropriate exit router when contacting a		scenario is to select the appropriate exit router when contacting a
	given DOTS server.		given DOTS server.
	An alternative deployment scheme is shown in Figure 9:		An alternative deployment scheme is shown in Figure 9:
	* DOTS clients are enabled in hosts located in the internal network.		* DOTS clients are enabled in hosts located in the internal network.
	* A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2		* A client-domain DOTS gateway is enabled in each CPE (CPE1 and CPE2
	per Table 1).		per Table 1).
	* Each of these client-domain DOTS gateways communicates with the		* Each of these client-domain DOTS gateways communicates with the
	DOTS server of the provisioning domain.		DOTS server of the provisioning domain.
	+---+		.................................
	+------------| C1|----+		. +---+ .
	| +---+ |		. +------------| C1|----+ .
	| |		. | +---+ | .
	+--+ +-+-+ +---+ +-+-+ +--+		. | | .
			+--+ . +-+-+ +---+ +-+-+ . +--+
	|S2|------|G2 |------| C3|------|G1 |------|S1|		|S2|------|G2 |------| C3|------|G1 |------|S1|
	+--+ +-+-+ +---+ +-+-+ +--+		+--+ . +-+-+ +---+ +-+-+ . +--+
	rtr2 rtr1		. CPE2 CPE1 .
	| +---+ |		. | +---+ | .
	+------------| C2|----+		. +------------| C2|----+ .
	+---+		. +---+ .
			'...............................'
			DOTS Client Domain
	Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple		Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple
	DOTS Servers		DOTS Servers
	When PI addresses/prefixes are used, DOTS clients MUST contact all		When PI addresses/prefixes are used, DOTS clients MUST contact all
	the client-domain DOTS gateways to send a DOTS message. Client-		the client-domain DOTS gateways to send a DOTS message. Client-
	domain DOTS gateways will then relay the request to the DOTS servers		domain DOTS gateways will then relay the request to the DOTS servers
	as a function of local policy. Note that anycast addresses cannot be		as a function of local policy. Note that anycast addresses cannot be
	used to establish DOTS sessions between DOTS clients and client-		used to establish DOTS sessions between DOTS clients and client-
	domain DOTS gateways because only one DOTS gateway will receive the		domain DOTS gateways because only one DOTS gateway will receive the
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 17 ¶
	* Distinct DOTS servers for each network attachment. These DOTS		* Distinct DOTS servers for each network attachment. These DOTS
	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
			A set of security threats related to multihoming are discussed in
			[RFC4218].
	DOTS-related security considerations are discussed in Section 4 of		DOTS-related security considerations are discussed in Section 4 of
	[RFC8811].		[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. In particular, if a DOTS client maintains DOTS		DOTS servers. In particular, if a DOTS client maintains DOTS
	sessions with specific DOTS servers per interconnection link, the		sessions 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 on different interconnection links that are not		DOTS servers on different interconnection links that are not
	authorized to mitigate attacks for that given link. Whether this		authorized to mitigate attacks for that given link. Whether this
	constraint is relaxed is deployment-specific and must be subject to		constraint is relaxed is deployment-specific and must be subject to
	skipping to change at page 14, line 48 ¶		skipping to change at page 14, line 44 ¶
	This document does not require any action from IANA.		This document does not require any action from IANA.
	8. Acknowledgements		8. Acknowledgements
	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.
	Thanks to Kathleen Moriarty for the secdir review and Joel Jaeggli		Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for
	for the opsdir review.		the opsdir review, and Mirja Kuhlewind for the tsvart review.
	Many thanks to Roman Danyliw for the careful AD review.		Many thanks to Roman Danyliw for the careful AD review.
	9. References		Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and
			Eric Vyncke for the IESG review.
			9. References
	9.1. Normative References		9.1. Normative References
	[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,
	skipping to change at page 15, line 40 ¶		skipping to change at page 15, line 37 ¶
	[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>.
			[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
			Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
			October 2005, <https://www.rfc-editor.org/info/rfc4218>.
	[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet		[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
	Denial-of-Service Considerations", RFC 4732,		Denial-of-Service Considerations", RFC 4732,
	DOI 10.17487/RFC4732, December 2006,		DOI 10.17487/RFC4732, December 2006,
	<https://www.rfc-editor.org/info/rfc4732>.		<https://www.rfc-editor.org/info/rfc4732>.
	[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>.
			[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
			Threat Signaling (DOTS) Requirements", RFC 8612,
			DOI 10.17487/RFC8612, May 2019,
			<https://www.rfc-editor.org/info/rfc8612>.
	[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed		[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Data		Denial-of-Service Open Threat Signaling (DOTS) Data
	Channel Specification", RFC 8783, DOI 10.17487/RFC8783,		Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
	May 2020, <https://www.rfc-editor.org/info/rfc8783>.		May 2020, <https://www.rfc-editor.org/info/rfc8783>.
	[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S.,		[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S.,
	Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol",		Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol",
	RFC 8803, DOI 10.17487/RFC8803, July 2020,		RFC 8803, DOI 10.17487/RFC8803, July 2020,
	<https://www.rfc-editor.org/info/rfc8803>.		<https://www.rfc-editor.org/info/rfc8803>.
End of changes. 32 change blocks.
	79 lines changed or deleted		99 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/