< draft-ietf-dots-multihoming-02.txt		draft-ietf-dots-multihoming-03.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: January 23, 2020 McAfee		Expires: July 25, 2020 McAfee
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	July 22, 2019		January 22, 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-02		draft-ietf-dots-multihoming-03
	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 January 23, 2020.		This Internet-Draft will expire on July 25, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 4		4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 4
	4.1. Residential Single CPE . . . . . . . . . . . . . . . . . 5		4.1. Residential Single CPE . . . . . . . . . . . . . . . . . 5
	4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream		4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 5		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7		4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7
	5. DOTS Deployment Considerations . . . . . . . . . . . . . . . 7		5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 11		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 12		5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	o That router is connected to multiple provisioning domains (i.e.,		o That router is connected to multiple provisioning domains (i.e.,
	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.
	+------+ +------+		+------+ +------+
	| ISP1 | | ISP2 |		| ISP1 | | ISP2 |
	+---+--+ +--+---+		+---+--+ +--+---+
	| | Service Providers		| | Service Providers
	............|....................|.......................		............|....................|.......................
	+---------++---------+ Enterprise Network		+---------++---------+ Enterprise Network
	||		||
	+--++-+		+--++-+
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 29 ¶
	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 Section 4.2 and Section 4.3 in which
	multi-homing is supported by the same ISP (i.e., same provisioning		multi-homing is supported by the same ISP (i.e., same provisioning
	domain).		domain).
	Editor's Note: The use of anycast addresses is to be consistently		Editor's Note: The use of anycast addresses is to be consistently
	discussed.		discussed.
	5. DOTS 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 | DOTS |		| Scenario | DOTS client | DOTS |
	| | | gateway |		| | | gateway |
	+---------------------------+-------------------------+-------------+		+---------------------------+-------------------------+-------------+
	| Residential CPE | CPE | N/A |		| Residential CPE | CPE | N/A |
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	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.		the scenario described in Section 4.1.
	For each provisioning domain, the DOTS client MUST resolve the DOTS		For each provisioning domain, the DOTS client MUST resolve the DOTS
	server's name provided by a provisioning domain		server's name provided by a provisioning domain
	([I-D.boucadair-dots-server-discovery]) using the DNS servers learned		([I-D.boucadair-dots-server-discovery]) using the DNS servers learned
	from the respective provisioning domain. The DOTS client MUST use		from the respective provisioning domain. IPv6-capable DOTS clients
	the source address selection algorithm defined in [RFC6724] to select		MUST use the source address selection algorithm defined in [RFC6724]
	the candidate source addresses to contact each of these DOTS servers.		to select the candidate source addresses to contact each of these
	DOTS sessions must be established and maintained with each of the		DOTS servers. DOTS sessions MUST be established and maintained with
	DOTS servers because the mitigation scope of these servers is		each of the DOTS servers because the mitigation scope of these
	restricted. The DOTS client SHOULD use the certificate provisioned		servers is restricted. The DOTS client SHOULD use the certificate
	by a provisioning domain to authenticate itself to the DOTS server		provisioned by a provisioning domain to authenticate itself to the
	provided by the same provisioning domain.		DOTS server provided by the same provisioning domain.
	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 among the DOTS servers available MUST select a DOTS		the DOTS client among the DOTS servers available MUST select a DOTS
	server whose network has assigned the prefixes from which target		server whose network has assigned the prefixes from which target
	prefixes and target IP addresses are derived. This implies that if		prefixes and target IP addresses are derived. This implies that if
	no appropriate DOTS server is found, the DOTS client must not send		no appropriate DOTS server is found, the DOTS client MUST NOT send
	the mitigation request to any DOTS server.		the mitigation request to any 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
	domain another domain than the one that owns those addresses/		domain another domain than the one that owns those addresses/
	prefixes. Consequently, if a CPE detects a DDoS attack that spreads		prefixes. Consequently, if a CPE detects a DDoS attack that spreads
	over all its network attachments, it must contact both DOTS servers		over all its network attachments, it MUST contact both DOTS servers
	for mitigation purposes. Nevertheless, if the DDoS attack is		for mitigation purposes. Nevertheless, if the DDoS attack is
	received from one single network, then only the DOTS server of that		received from one single network, then only the DOTS server of that
	network must be contacted.		network MUST be contacted.
	The DOTS client MUST be able to associate a DOTS server with each		The DOTS client MUST be able to associate a DOTS server with each
	provisioning domain. For example, if the DOTS client is provisioned		provisioning domain. For example, if the DOTS client is provisioned
	with S1 using DHCP when attaching to a first network and with S2		with S1 using DHCP when attaching to a first network and with S2
	using Protocol Configuration Option (PCO) when attaching to a second		using Protocol Configuration Option (PCO) when attaching to a second
	network, the DOTS client must record the interface from which a DOTS		network, the DOTS client must record the interface from which a DOTS
	server was provisioned. DOTS signaling session to a given DOTS		server was provisioned. DOTS signaling session to a given DOTS
	server must be established using the interface from which the DOTS		server must be established using the interface from which the DOTS
	server was provisioned.		server was provisioned.
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	o A DOTS gateway is enabled to aggregate and then relay the requests		o A DOTS gateway is enabled to aggregate and then relay the requests
	towards upstream DOTS servers.		towards upstream 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 DOTS gateway to		discussed in Section 5.1 need to be followed by the DOTS gateway to
	contact its DOTS server(s). The DOTS gateways can be reachable from		contact its DOTS server(s). The DOTS gateways can be reachable from
	DOTS clients by using an unicast address or an anycast address.		DOTS clients by using an unicast address or an anycast address.
	Nevertheless, when PI addresses/prefixes are assigned, the DOTS		Nevertheless, when PI addresses/prefixes are assigned, the DOTS
	gateway MUST send the same request to all its DOTS servers.		gateway MUST send mitigation requests to all its DOTS servers.
			Otherwise, the attack traffic may still be delivered via the ISP
			which hasn't received the mitigation request.
	+--+		+--+
	-----------|S1|		-----------|S1|
	+---+ / +--+		+---+ / +--+
	| C1|----+ /		| C1|----+ /
	+---+ | /		+---+ | /
	+---+ +-+-+/		+---+ +-+-+/
	| C3|------| G |		| C3|------| G |
	+---+ +-+-+\		+---+ +-+-+\
	+---+ | \		+---+ | \
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 43 ¶
	deployment assumes that:		deployment assumes that:
	o One or more DOTS clients are enabled in hosts located in the		o One or more DOTS clients are enabled in hosts located in the
	internal network. These DOTS clients may use		internal network. These DOTS clients may use
	[I-D.boucadair-dots-server-discovery] to discover their DOTS		[I-D.boucadair-dots-server-discovery] to discover their DOTS
	server(s).		server(s).
	o These DOTS clients communicate directly with upstream DOTS		o These DOTS clients communicate directly with upstream DOTS
	servers.		servers.
	If PI addresses/prefixes are in use, the DOTS client MUST send the		If PI addresses/prefixes are in use, the DOTS client MUST send a
	mitigation request for all its PI addresses/prefixes to all the DOTS		mitigation request to all the DOTS servers. The use of anycast
	servers. The use of anycast addresses is NOT RECOMMENDED.		addresses to reach the DOTS servers is NOT RECOMMENDED.
	If PA addresses/prefixes are used, the same considerations discussed		If PA addresses/prefixes are used, the same considerations discussed
	in Section 5.1 need to be followed by the DOTS clients. Because DOTS		in Section 5.1 need to be followed by the DOTS clients. Because DOTS
	clients are not embedded in the CPE and multiple addreses/prefixes		clients are not embedded in the CPE and multiple addreses/prefixes
	may not be assigned to the DOTS client (typically in an IPv4		may not be assigned to the DOTS client (typically in an IPv4
	context), some issues arise to steer traffic towards the appropriate		context), some issues arise to steer traffic towards the appropriate
	DOTS server by using the appropriate source IP address. These		DOTS server by using the appropriate source IP address. These
	complications discussed in [RFC4116] are not specific to DOTS.		complications discussed in [RFC4116] are not specific to DOTS.
	+--+		+--+
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 32 ¶
	+--+		+--+
	+--------|C1|		+--------|C1|
	| +--+		| +--+
	+--+ +--+ +--+		+--+ +--+ +--+
	|S2| |C2|------|S1|		|S2| |C2|------|S1|
	+--+ +--+ +--+		+--+ +--+ +--+
	Figure 8: Single Homed DOTS Clients		Figure 8: Single Homed DOTS Clients
	Each DOTS client is provided with policies (e.g., prefix filter) that		Each DOTS client SHOULD be provided with policies (e.g., a prefix
	will trigger DOTS communications with the DOTS servers. Such		filter that will be against DDoS detection alarms) that will trigger
	policies will help the DOTS client to select the appropriate		DOTS communications with the DOTS servers. Such policies will help
	destination IP address.		the DOTS client to select the appropriate destination DOTS server.
	The CPE MUST select the appropriate source IP address when forwarding		The CPE MUST select the appropriate source IP address when forwarding
	DOTS messages received from an internal DOTS client. If anycast		DOTS messages received from an internal DOTS client. If anycast
	addresses are used to reach DOTS servers, the CPE may not be able to		addresses are used to reach DOTS servers, the CPE may not be able to
	select the appropriate provisioning domain to which the mitigation		select the appropriate provisioning domain to which the mitigation
	request should be forwarded. As a consequence, the request may not		request should be forwarded. As a consequence, the request may not
	be forwarded to the appropriate DOTS server.		be forwarded to the appropriate DOTS server.
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	skipping to change at page 13, line 39 ¶		skipping to change at page 13, line 41 ¶
	and Christian Jacquenet for sharing their comments on the mailing		and Christian Jacquenet for sharing their comments on the mailing
	list.		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]		[I-D.ietf-dots-architecture]
	Mortensen, A., K, R., Andreasen, F., Teague, N., and R.		Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
	Compton, "Distributed-Denial-of-Service Open Threat		R. Compton, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-		Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-14 (work in progress), May 2019.		architecture-15 (work in progress), January 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>.
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 23 ¶
	9.2. Informative References		9.2. Informative References
	[I-D.boucadair-dots-server-discovery]		[I-D.boucadair-dots-server-discovery]
	Boucadair, M., K, R., and P. Patil, "Distributed-Denial-		Boucadair, M., K, R., and P. Patil, "Distributed-Denial-
	of-Service Open Threat Signaling (DOTS) Server Discovery",		of-Service Open Threat Signaling (DOTS) Server Discovery",
	draft-boucadair-dots-server-discovery-05 (work in		draft-boucadair-dots-server-discovery-05 (work in
	progress), October 2018.		progress), October 2018.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and R. K, "Distributed Denial-of-Service		Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
	Open Threat Signaling (DOTS) Data Channel Specification",		Service Open Threat Signaling (DOTS) Data Channel
	draft-ietf-dots-data-channel-30 (work in progress), July		Specification", draft-ietf-dots-data-channel-31 (work in
	2019.		progress), July 2019.
	[I-D.ietf-dots-signal-channel]		[I-D.ietf-dots-signal-channel]
	K, R., Boucadair, M., Patil, P., Mortensen, A., and N.		Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
	Teague, "Distributed Denial-of-Service Open Threat		N. Teague, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification", draft-		Signaling (DOTS) Signal Channel Specification", draft-
	ietf-dots-signal-channel-35 (work in progress), July 2019.		ietf-dots-signal-channel-41 (work in progress), January
			2020.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Open Threat Signaling", draft-ietf-dots-use-cases-18 (work		Signaling", draft-ietf-dots-use-cases-20 (work in
	in progress), July 2019.		progress), September 2019.
	[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>.
End of changes. 21 change blocks.
	41 lines changed or deleted		44 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/