< draft-ietf-dots-multihoming-03.txt		draft-ietf-dots-multihoming-04.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: July 25, 2020 McAfee		Expires: November 30, 2020 McAfee
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	January 22, 2020		May 29, 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-03		draft-ietf-dots-multihoming-04
	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 July 25, 2020.		This Internet-Draft will expire on November 30, 2020.
	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 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	(Customer Premises Equipment).		(Customer Premises Equipment).
	o The CPE is connected to multiple provisioning domains (i.e., both		o The CPE is connected to multiple provisioning domains (i.e., both
	fixed and mobile networks). Provisioning domain (PvD) is		fixed and mobile networks). Provisioning domain (PvD) is
	explained in [RFC7556].		explained in [RFC7556].
	o Each of these provisioning domains assigns IP addresses/prefixes		o Each of these provisioning domains assigns IP addresses/prefixes
	to the CPE and provides additional configuration information such		to the CPE and provides additional configuration information such
	as a list of DNS servers, DNS suffixes associated with the		as a list of DNS servers, DNS suffixes associated with the
	network, default gateway address, and DOTS server's name		network, default gateway address, and DOTS server's name
	[I-D.boucadair-dots-server-discovery]. These addresses/prefixes		[I-D.ietf-dots-server-discovery]. These addresses/prefixes are
	are assumed to be Provider-Aggregatable (PA).		assumed to be Provider-Aggregatable (PA).
	o Because of ingress filtering, packets forwarded by the CPE towards		o Because of ingress filtering, packets forwarded by the CPE towards
	a given provisioning domain must be sent with a source IP address		a given provisioning domain must be sent with a source IP address
	that was assigned by that domain [RFC8043].		that was assigned by that domain [RFC8043].
	+-------+ +-------+		+-------+ +-------+
	|Fixed | |Mobile |		|Fixed | |Mobile |
	|Network| |Network|		|Network| |Network|
	+---+---+ +---+---+		+---+---+ +---+---+
	| | Service Providers		| | Service Providers
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 35 ¶
	sections.		sections.
	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.ietf-dots-server-discovery]) using the DNS servers learned from
	from the respective provisioning domain. IPv6-capable DOTS clients		the respective provisioning domain. IPv6-capable DOTS clients MUST
	MUST use the source address selection algorithm defined in [RFC6724]		use the source address selection algorithm defined in [RFC6724] to
	to select the candidate source addresses to contact each of these		select the candidate source addresses to contact each of these DOTS
	DOTS servers. DOTS sessions MUST be established and maintained with		servers. DOTS sessions MUST be established and maintained with each
	each of the DOTS servers because the mitigation scope of these		of the DOTS servers because the mitigation scope of these servers is
	servers is restricted. The DOTS client SHOULD use the certificate		restricted. The DOTS client SHOULD use the certificate provisioned
	provisioned by a provisioning domain to authenticate itself to the		by a provisioning domain to authenticate itself to the DOTS server
	DOTS server provided by the same provisioning domain.		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
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	/		/
	+---+/		+---+/
	| C |		| C |
	+---+\		+---+\
	\		\
	\		\
	\ +--+		\ +--+
	-----------|S2|		-----------|S2|
	+--+		+--+
	Figure 5: DOTS associations for a multihomed residential CPE		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 a first set of DOTS associations that can be		Figure 6 illustrates a first set of DOTS associations that can be
	established with a DOTS gateway, which is enabled within the context		established with a DOTS gateway, which is enabled within the context
	of the scenario described in Section 4.2. This deployment is		of the scenario described in Section 4.2. This deployment is
	characterized as follows:		characterized as follows:
	o One of more DOTS clients are enabled in hosts located in the		o One of more DOTS clients are enabled in hosts located in the
	internal network.		internal network.
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 37 ¶
	+--+		+--+
	Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS		Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS
	Servers		Servers
	An alternate deployment model is depicted in Figure 7. This		An alternate deployment model is depicted in Figure 7. This
	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.ietf-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 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 the DOTS servers 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
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 18 ¶
	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].		[I-D.ietf-dots-architecture].
	TBD: In Home networks, if EST is used then how will the DOTS gateway		DOTS clients should control the information that they share with peer
	(EST client) be provisioned with credentials for initial enrolment		DOTS servers. For example, if a DOTS client maintains DOTS
	(see Section 2.2 in RFC 7030).		associations with specific DOTS servers per interconnection link, the
			DOTS client should not leak information specific to a given link to
			DOTS servers not authorized to mitigate attacks received on that
			link. Whether this constraint is relaxed is deployment specific and
			must be subject to explicit consent from the DOTS client domain
			administrator.
	7. IANA Considerations		7. IANA Considerations
	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, Wei Pan,		Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and
	and Christian Jacquenet for sharing their comments on the mailing		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., Reddy.K, T., Andreasen, F., Teague, N., and		Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
	R. 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-15 (work in progress), January 2020.		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		9.2. Informative References
	[I-D.boucadair-dots-server-discovery]
	Boucadair, M., K, R., and P. Patil, "Distributed-Denial-
	of-Service Open Threat Signaling (DOTS) Server Discovery",
	draft-boucadair-dots-server-discovery-05 (work in
	progress), October 2018.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and T. Reddy.K, "Distributed Denial-of-		Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel		Service Open Threat Signaling (DOTS) Data Channel
	Specification", draft-ietf-dots-data-channel-31 (work in		Specification", draft-ietf-dots-data-channel-31 (work in
	progress), July 2019.		progress), July 2019.
			[I-D.ietf-dots-server-discovery]
			Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
			Service Open Threat Signaling (DOTS) Agent Discovery",
			draft-ietf-dots-server-discovery-10 (work in progress),
			February 2020.
	[I-D.ietf-dots-signal-channel]		[I-D.ietf-dots-signal-channel]
	Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and		Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
	N. 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-41 (work in progress), January		ietf-dots-signal-channel-41 (work in progress), January
	2020.		2020.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	L., and K. Nishizuka, "Use cases for DDoS Open Threat		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Signaling", draft-ietf-dots-use-cases-20 (work in		Signaling", draft-ietf-dots-use-cases-21 (work in
	progress), September 2019.		progress), May 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>.
End of changes. 14 change blocks.
	33 lines changed or deleted		36 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/