draft-ietf-dots-requirements-20.txt		draft-ietf-dots-requirements-21.txt
	DOTS A. Mortensen		DOTS A. Mortensen
	Internet-Draft Arbor Networks		Internet-Draft Arbor Networks
	Intended status: Informational T. Reddy		Intended status: Informational T. Reddy
	Expires: September 2, 2019 McAfee		Expires: September 10, 2019 McAfee
	R. Moskowitz		R. Moskowitz
	Huawei		Huawei
	March 1, 2019		March 9, 2019
	Distributed Denial of Service (DDoS) Open Threat Signaling Requirements		Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
	draft-ietf-dots-requirements-20		draft-ietf-dots-requirements-21
	Abstract		Abstract
	This document defines the requirements for the Distributed Denial of		This document defines the requirements for the Distributed Denial of
	Service (DDoS) Open Threat Signaling (DOTS) protocols enabling		Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
	coordinated response to DDoS attacks.		coordinated response to DDoS attacks.
	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 35 ¶		skipping to change at page 1, line 35 ¶
	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 September 2, 2019.		This Internet-Draft will expire on September 10, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	be able to request scoped mitigation from DOTS servers. DOTS		be able to request scoped mitigation from DOTS servers. DOTS
	servers MUST send status to the DOTS clients about mitigation		servers MUST send status to the DOTS clients about mitigation
	requests. If a DOTS server rejects an authorized request for		requests. If a DOTS server rejects an authorized request for
	mitigation, the DOTS server MUST include a reason for the		mitigation, the DOTS server MUST include a reason for the
	rejection in the status message sent to the client.		rejection in the status message sent to the client.
	DOTS servers MUST regularly send mitigation status updates to		DOTS servers MUST regularly send mitigation status updates to
	authorized DOTS clients which have requested and been granted		authorized DOTS clients which have requested and been granted
	mitigation. If unreliable transport is used for the signal		mitigation. If unreliable transport is used for the signal
	channel protocol, due to the higher likelihood of packet loss		channel protocol, due to the higher likelihood of packet loss
	during a DDoS attack, DOTS servers MUST send mitigation status		during a DDoS attack, DOTS servers needs to send mitigation status
	multiple times at regular intervals following the the data		multiple times at regular intervals following the the data
	transmission guidelines discussed in Section 3.1.3 of [RFC8085].		transmission guidelines discussed in Section 3.1.3 of [RFC8085].
	When DOTS client-requested mitigation is active, DOTS server		When DOTS client-requested mitigation is active, DOTS server
	status messages MUST include the following mitigation metrics:		status messages MUST include the following mitigation metrics:
	* Total number of packets blocked by the mitigation		* Total number of packets blocked by the mitigation
	* Current number of packets per second blocked		* Current number of packets per second blocked
	skipping to change at page 14, line 37 ¶		skipping to change at page 14, line 37 ¶
	2.4. Security Requirements		2.4. Security Requirements
	DOTS must operate within a particularly strict security context, as		DOTS must operate within a particularly strict security context, as
	an insufficiently protected signal or data channel may be subject to		an insufficiently protected signal or data channel may be subject to
	abuse, enabling or supplementing the very attacks DOTS purports to		abuse, enabling or supplementing the very attacks DOTS purports to
	mitigate.		mitigate.
	SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate		SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate
	each other before a DOTS signal or data channel is considered		each other before a DOTS signal or data channel is considered
	valid. The method of authentication is not specified in this		valid. The method of authentication is not specified in this
	document, but should follow current IETF best practices (like		document, but should follow current IETF best practices [RFC7525]
	[RFC7525]) with respect to any cryptographic mechanisms to		with respect to any cryptographic mechanisms to authenticate the
	authenticate the remote peer.		remote peer.
	SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS		SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS
	protocols MUST take steps to protect the confidentiality,		protocols MUST take steps to protect the confidentiality,
	integrity and authenticity of messages sent between client and		integrity and authenticity of messages sent between client and
	server. While specific transport- and message-level security		server. While specific transport- and message-level security
	options are not specified, the protocols MUST follow current IETF		options are not specified, the protocols MUST follow current IETF
	best practices (like [RFC7525]) for encryption and message		best practices [RFC7525] for encryption and message
	authentication. Client-domain DOTS gateways are more trusted than		authentication. Client-domain DOTS gateways are more trusted than
	DOTS clients, while server-domain DOTS gateways and DOTS servers		DOTS clients, while server-domain DOTS gateways and DOTS servers
	share the same level of trust. A security mechanism at the		share the same level of trust. A security mechanism at the
	transport layer (e.g., TLS) is thus adequate to provide security		transport layer (e.g., TLS) is thus adequate to provide security
	between peer DOTS agents.		between peer DOTS agents.
	In order for DOTS protocols to remain secure despite advancements		In order for DOTS protocols to remain secure despite advancements
	in cryptanalysis and traffic analysis, DOTS agents MUST support		in cryptanalysis and traffic analysis, DOTS agents MUST support
	secure negotiation of the terms and mechanisms of protocol		secure negotiation of the terms and mechanisms of protocol
	security, subject to the interoperability and signal message size		security, subject to the interoperability and signal message size
	skipping to change at page 20, line 50 ¶		skipping to change at page 20, line 50 ¶
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-dots-architecture]		[I-D.ietf-dots-architecture]
	Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,		Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
	R., and c. christopher_gray3@cable.comcast.com,		R., and c. christopher_gray3@cable.comcast.com,
	"Distributed-Denial-of-Service Open Threat Signaling		"Distributed-Denial-of-Service Open Threat Signaling
	(DOTS) Architecture", draft-ietf-dots-architecture-11		(DOTS) Architecture", draft-ietf-dots-architecture-12
	(work in progress), February 2019.		(work in progress), February 2019.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,		Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
	Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS		Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
	Open Threat Signaling", draft-ietf-dots-use-cases-17 (work		Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
	in progress), January 2019.		in progress), January 2019.
	[I-D.ietf-intarea-frag-fragile]		[I-D.ietf-intarea-frag-fragile]
	Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,		Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
End of changes. 8 change blocks.
	10 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/