draft-ietf-dots-requirements-19.txt		draft-ietf-dots-requirements-20.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: August 29, 2019 McAfee		Expires: September 2, 2019 McAfee
	R. Moskowitz		R. Moskowitz
	Huawei		Huawei
	February 25, 2019		March 1, 2019
	Distributed Denial of Service (DDoS) Open Threat Signaling Requirements		Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
	draft-ietf-dots-requirements-19		draft-ietf-dots-requirements-20
	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 August 29, 2019.		This Internet-Draft will expire on September 2, 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 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	signaling Path Maximum Transmission Unit (PMTU), including the		signaling Path Maximum Transmission Unit (PMTU), including the
	byte overhead of any encapsulation, transport headers, and		byte overhead of any encapsulation, transport headers, and
	transport- or message-level security. If the total message size		transport- or message-level security. If the total message size
	exceeds the path MTU, the DOTS agent MUST split the message into		exceeds the path MTU, the DOTS agent MUST split the message into
	separate messages; for example, the list of mitigation scope types		separate messages; for example, the list of mitigation scope types
	could be split into multiple lists and each list conveyed in a new		could be split into multiple lists and each list conveyed in a new
	message.		message.
	DOTS agents can attempt to learn PMTU using the procedures		DOTS agents can attempt to learn PMTU using the procedures
	discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot		discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot
	be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for		be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as
	IPv6. If the PMTU cannot be discovered, DOTS agents MUST assume a		IPv6 requires that every link in the Internet have an MTU of 1280
	PMTU of 1280 bytes, as IPv6 requires that every link in the		octets or greater as specified in [RFC8200]. If IPv4 support on
	Internet have an MTU of 1280 octets or greater as specified in		legacy or otherwise unusual networks is a consideration and the
	[RFC8200]. If IPv4 support on legacy or otherwise unusual		PMTU is unknown, DOTS implementations MAY assume on a PMTU of 576
	networks is a consideration and the PMTU is unknown, DOTS		bytes for IPv4 datagrams, as every IPv4 host must be capable of
	implementations MAY assume on a PMTU of 576 bytes for IPv4		receiving a packet whose length is equal to 576 bytes as discussed
	datagrams, as every IPv4 host must be capable of receiving a		in [RFC0791] and [RFC1122].
	packet whose length is equal to 576 bytes as discussed in
	[RFC0791] and [RFC1122].
	SIG-003 Bidirectionality: To support peer health detection, to		SIG-003 Bidirectionality: To support peer health detection, to
	maintain an active signal channel, and to increase the probability		maintain an active signal channel, and to increase the probability
	of signal delivery during an attack, the signal channel MUST be		of signal delivery during an attack, the signal channel MUST be
	bidirectional, with client and server transmitting signals to each		bidirectional, with client and server transmitting signals to each
	other at regular intervals, regardless of any client request for		other at regular intervals, regardless of any client request for
	mitigation. The bidirectional signal channel MUST support		mitigation. The bidirectional signal channel MUST support
	unidirectional messaging to enable notifications between DOTS		unidirectional messaging to enable notifications between DOTS
	agents.		agents.
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	defunct.		defunct.
	SIG-005 Channel Redirection: In order to increase DOTS operational		SIG-005 Channel Redirection: In order to increase DOTS operational
	flexibility and scalability, DOTS servers SHOULD be able to		flexibility and scalability, DOTS servers SHOULD be able to
	redirect DOTS clients to another DOTS server at any time. DOTS		redirect DOTS clients to another DOTS server at any time. DOTS
	clients MUST NOT assume the redirection target DOTS server shares		clients MUST NOT assume the redirection target DOTS server shares
	security state with the redirecting DOTS server. DOTS clients are		security state with the redirecting DOTS server. DOTS clients are
	free to attempt abbreviated security negotiation methods supported		free to attempt abbreviated security negotiation methods supported
	by the protocol, such as DTLS session resumption, but MUST be		by the protocol, such as DTLS session resumption, but MUST be
	prepared to negotiate new security state with the redirection		prepared to negotiate new security state with the redirection
	target DOTS server. The authentication domain of the redirection		target DOTS server. The redirection DOTS server and redirecting
	target DOTS server MUST be the same as the authentication domain		DOTS server MUST belong to the same administrative domain.
	of the redirecting DOTS server.
	Due to the increased likelihood of packet loss caused by link		Due to the increased likelihood of packet loss caused by link
	congestion during an attack, DOTS servers SHOULD NOT redirect		congestion during an attack, DOTS servers SHOULD NOT redirect
	while mitigation is enabled during an active attack against a		while mitigation is enabled during an active attack against a
	target in the DOTS client's domain.		target in the DOTS client's domain.
	SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST		SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST
	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
End of changes. 6 change blocks.
	17 lines changed or deleted		14 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/