Diff: rfc8973v2.txt - rfc8973.txt

	rfc8973v2.txt	rfc8973.txt

	skipping to change at line 98 ¶	skipping to change at line 98 ¶

	DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture	DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture
	in which a DOTS client can inform a DOTS server that the network is	in which a DOTS client can inform a DOTS server that the network is
	under a potential attack and that appropriate mitigation actions are	under a potential attack and that appropriate mitigation actions are
	required. Indeed, because the lack of a common method to coordinate	required. Indeed, because the lack of a common method to coordinate
	a real-time response among involved actors and network domains	a real-time response among involved actors and network domains
	inhibits the effectiveness of DDoS attack mitigation, the DOTS signal	inhibits the effectiveness of DDoS attack mitigation, the DOTS signal
	channel protocol [RFC8782] is meant to carry requests for DDoS attack	channel protocol [RFC8782] is meant to carry requests for DDoS attack
	mitigation. With this approach, DOTS can reduce the impact of an	mitigation. With this approach, DOTS can reduce the impact of an
	attack and lead to more efficient defensive actions in various	attack and lead to more efficient defensive actions in various

	deployment scenarios, such as those discussed in [RFC8903].	deployment scenarios, such as those discussed in [DOTS-USE-CASES].
	Moreover, DOTS clients can instruct a DOTS server to install named	Moreover, DOTS clients can instruct a DOTS server to install named
	filtering rules by means of the DOTS data channel protocol [RFC8783].	filtering rules by means of the DOTS data channel protocol [RFC8783].

	The basic high-level DOTS architecture is illustrated in Figure 1.	The basic high-level DOTS architecture is illustrated in Figure 1.

	+-----------+ +-------------+	+-----------+ +-------------+
	\| Mitigator \| ~~~~~~~~~~ \| DOTS Server \|	\| Mitigator \| ~~~~~~~~~~ \| DOTS Server \|
	+-----------+ +------+------+	+-----------+ +------+------+
	\|	\|
	\|	\|

	skipping to change at line 195 ¶	skipping to change at line 195 ¶

	DOTS agent: is any DOTS-aware software module capable of	DOTS agent: is any DOTS-aware software module capable of
	participating in a DOTS channel.	participating in a DOTS channel.

	Peer DOTS agent: refers to the peer DOTS server (base DOTS	Peer DOTS agent: refers to the peer DOTS server (base DOTS
	operation) or to a peer Call Home DOTS client (for DOTS signal	operation) or to a peer Call Home DOTS client (for DOTS signal
	channel Call Home).	channel Call Home).

	3. Why Multiple Discovery Mechanisms?	3. Why Multiple Discovery Mechanisms?


	Analysis of the various use cases sketched in [RFC8903] reveals that	Analysis of the various use cases sketched in [DOTS-USE-CASES]
	it is unlikely that one single discovery method can be suitable for	reveals that it is unlikely that one single discovery method can be
	all the sample deployments. Concretely:	suitable for all the sample deployments. Concretely:


	* Many of the use cases discussed in [RFC8903] do involve Customer	* Many of the use cases discussed in [DOTS-USE-CASES] do involve
	Premises Equipment (CPE). Multiple CPEs connected to distinct	Customer Premises Equipment (CPE). Multiple CPEs connected to
	network providers may even be considered. It is intuitive to	distinct network providers may even be considered. It is
	leverage existing mechanisms, such as discovery using service	intuitive to leverage existing mechanisms, such as discovery using
	resolution or DHCP, to provision the CPE acting as a DOTS client	service resolution or DHCP, to provision the CPE acting as a DOTS
	with the DOTS server(s).	client with the DOTS server(s).

	* Resolving a DOTS server domain name offered by an upstream transit	* Resolving a DOTS server domain name offered by an upstream transit
	provider provisioned to a DOTS client into IP address(es) requires	provider provisioned to a DOTS client into IP address(es) requires
	the use of the appropriate DNS resolvers; otherwise, resolving	the use of the appropriate DNS resolvers; otherwise, resolving
	those names will fail. The use of protocols, such as DHCP, does	those names will fail. The use of protocols, such as DHCP, does
	allow associating provisioned DOTS server domain names with a list	allow associating provisioned DOTS server domain names with a list
	of DNS servers to be used for name resolution. Furthermore, DHCP	of DNS servers to be used for name resolution. Furthermore, DHCP
	allows for directly providing IP addresses, therefore, avoiding	allows for directly providing IP addresses, therefore, avoiding
	the need for extra lookup delays.	the need for extra lookup delays.


	skipping to change at line 1062 ¶	skipping to change at line 1062 ¶
	dots-multihoming-05>.	dots-multihoming-05>.

	[DOTS-SIG-CALL-HOME]	[DOTS-SIG-CALL-HOME]
	Reddy, T., Boucadair, M., and J. Shallow, "Distributed	Reddy, T., Boucadair, M., and J. Shallow, "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Signal	Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Call Home", Work in Progress, Internet-Draft,	Channel Call Home", Work in Progress, Internet-Draft,
	draft-ietf-dots-signal-call-home-12, 23 December 2020,	draft-ietf-dots-signal-call-home-12, 23 December 2020,
	<https://tools.ietf.org/html/draft-ietf-dots-signal-call-	<https://tools.ietf.org/html/draft-ietf-dots-signal-call-
	home-12>.	home-12>.


		[DOTS-USE-CASES]
		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
		L., and K. Nishizuka, "Use cases for DDoS Open Threat
		Signaling", Work in Progress, Internet-Draft, draft-ietf-
		dots-use-cases-25, 5 July 2020,
		<https://tools.ietf.org/html/draft-ietf-dots-use-cases-
		25>.

	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",	"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, DOI 10.17487/RFC2136, April 1997,	RFC 2136, DOI 10.17487/RFC2136, April 1997,
	<https://www.rfc-editor.org/info/rfc2136>.	<https://www.rfc-editor.org/info/rfc2136>.

	[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic	[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
	Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,	Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
	<https://www.rfc-editor.org/info/rfc3007>.	<https://www.rfc-editor.org/info/rfc3007>.

	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.

	skipping to change at line 1113 ¶	skipping to change at line 1121 ¶
	[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>.

	[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,	[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
	Teague, N., and R. Compton, "DDoS Open Threat Signaling	Teague, N., and R. Compton, "DDoS Open Threat Signaling
	(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,	(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
	August 2020, <https://www.rfc-editor.org/info/rfc8811>.	August 2020, <https://www.rfc-editor.org/info/rfc8811>.


	[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	L., and K. Nishizuka, "Use Cases for DDoS Open Threat
	Signaling", RFC 8903, DOI 10.17487/RFC8903, December 2020,
	<https://www.rfc-editor.org/info/rfc8903>.

	Acknowledgements	Acknowledgements

	Thanks to Brian Carpenter for the review of the Bootstrapping Remote	Thanks to Brian Carpenter for the review of the Bootstrapping Remote
	Secure Key Infrastructure (BRSKI) text used in previous draft	Secure Key Infrastructure (BRSKI) text used in previous draft
	versions of the specification.	versions of the specification.

	Many thanks to Russ White for the review, comments, and text	Many thanks to Russ White for the review, comments, and text
	contribution.	contribution.

	Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the	Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the

End of changes. 5 change blocks.
	15 lines changed or deleted	18 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/