< draft-ietf-dots-signal-channel-29.txt		draft-ietf-dots-signal-channel-30.txt >
	DOTS T. Reddy, Ed.		DOTS T. Reddy, Ed.
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair, Ed.		Intended status: Standards Track M. Boucadair, Ed.
	Expires: August 26, 2019 Orange		Expires: September 6, 2019 Orange
	P. Patil		P. Patil
	Cisco		Cisco
	A. Mortensen		A. Mortensen
	Arbor Networks, Inc.		Arbor Networks, Inc.
	N. Teague		N. Teague
	Verisign, Inc.		Verisign, Inc.
	February 22, 2019		March 5, 2019
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal		Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Specification		Channel Specification
	draft-ietf-dots-signal-channel-29		draft-ietf-dots-signal-channel-30
	Abstract		Abstract
	This document specifies the DOTS signal channel, a protocol for		This document specifies the DOTS signal channel, a protocol for
	signaling the need for protection against Distributed Denial-of-		signaling the need for protection against Distributed Denial-of-
	Service (DDoS) attacks to a server capable of enabling network		Service (DDoS) attacks to a server capable of enabling network
	traffic mitigation on behalf of the requesting client.		traffic mitigation on behalf of the requesting client.
	A companion document defines the DOTS data channel, a separate		A companion document defines the DOTS data channel, a separate
	reliable communication layer for DOTS management and configuration		reliable communication layer for DOTS management and configuration
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 26, 2019.		This Internet-Draft will expire on September 6, 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 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	target-prefix: A list of prefixes identifying resources under		target-prefix: A list of prefixes identifying resources under
	attack. Prefixes are represented using Classless Inter-Domain		attack. Prefixes are represented using Classless Inter-Domain
	Routing (CIDR) notation [RFC4632].		Routing (CIDR) notation [RFC4632].
	As a reminder, the prefix length must be less than or equal to 32		As a reminder, the prefix length must be less than or equal to 32
	(resp. 128) for IPv4 (resp. IPv6).		(resp. 128) for IPv4 (resp. IPv6).
	The prefix list MUST NOT include broadcast, loopback, or multicast		The prefix list MUST NOT include broadcast, loopback, or multicast
	addresses. These addresses are considered as invalid values. In		addresses. These addresses are considered as invalid values. In
	addition, the DOTS server MUST validate that target prefixes are		addition, the DOTS server MUST validate that target prefixes are
	within the scope of the DOTS client's domain. Other validation		within the scope of the DOTS client domain. Other validation
	checks may be supported by DOTS servers.		checks may be supported by DOTS servers.
	This is an optional attribute.		This is an optional attribute.
	target-port-range: A list of port numbers bound to resources under		target-port-range: A list of port numbers bound to resources under
	attack.		attack.
	A port range is defined by two bounds, a lower port number (lower-		A port range is defined by two bounds, a lower port number (lower-
	port) and an upper port number (upper-port). When only 'lower-		port) and an upper port number (upper-port). When only 'lower-
	port' is present, it represents a single port number.		port' is present, it represents a single port number.
	skipping to change at page 38, line 27 ¶		skipping to change at page 38, line 27 ¶
	limited period after acknowledging a DOTS client's withdrawal of a		limited period after acknowledging a DOTS client's withdrawal of a
	mitigation request. During this period, the DOTS server status		mitigation request. During this period, the DOTS server status
	messages SHOULD indicate that mitigation is active but terminating		messages SHOULD indicate that mitigation is active but terminating
	(Section 4.4.2).		(Section 4.4.2).
	The initial active-but-terminating period SHOULD be sufficiently long		The initial active-but-terminating period SHOULD be sufficiently long
	to absorb latency incurred by route propagation. The active-but-		to absorb latency incurred by route propagation. The active-but-
	terminating period SHOULD be set by default to 120 seconds. If the		terminating period SHOULD be set by default to 120 seconds. If the
	client requests mitigation again before the initial active-but-		client requests mitigation again before the initial active-but-
	terminating period elapses, the DOTS server MAY exponentially		terminating period elapses, the DOTS server MAY exponentially
	increase (the exponent is 2) the active-but-terminating period up to		increase (the base of the exponent is 2) the active-but-terminating
	a maximum of 300 seconds (5 minutes).		period up to a maximum of 300 seconds (5 minutes).
	Once the active-but-terminating period elapses, the DOTS server MUST		Once the active-but-terminating period elapses, the DOTS server MUST
	treat the mitigation as terminated, as the DOTS client is no longer		treat the mitigation as terminated, as the DOTS client is no longer
	responsible for the mitigation. For example, if there is a financial		responsible for the mitigation. For example, if there is a financial
	relationship between the DOTS client and server domains, the DOTS		relationship between the DOTS client and server domains, the DOTS
	client stops incurring cost at this point.		client stops incurring cost at this point.
	If a mitigation is triggered due to a signal channel loss, the DOTS		If a mitigation is triggered due to a signal channel loss, the DOTS
	server relies upon normal triggers to stop that mitigation		server relies upon normal triggers to stop that mitigation
	(typically, receipt of a valid DELETE request, expiry of the		(typically, receipt of a valid DELETE request, expiry of the
	skipping to change at page 39, line 23 ¶		skipping to change at page 39, line 23 ¶
	retransmission timeout value, and other message transmission		retransmission timeout value, and other message transmission
	parameters for the DOTS signal channel.		parameters for the DOTS signal channel.
	The same or distinct configuration sets may be used during times when		The same or distinct configuration sets may be used during times when
	a mitigation is active ('mitigating-config') and when no mitigation		a mitigation is active ('mitigating-config') and when no mitigation
	is active ('idle-config'). This is particularly useful for DOTS		is active ('idle-config'). This is particularly useful for DOTS
	servers that might want to reduce heartbeat frequency or cease		servers that might want to reduce heartbeat frequency or cease
	heartbeat exchanges when an active DOTS client has not requested		heartbeat exchanges when an active DOTS client has not requested
	mitigation. If distinct configurations are used, DOTS agents MUST		mitigation. If distinct configurations are used, DOTS agents MUST
	follow the appropriate configuration set as a function of the		follow the appropriate configuration set as a function of the
	mitigation activity (e.g., if no mitigation request is active, 'idle-		mitigation activity (e.g., if no mitigation request is active (also
	config'-related values must be followed). Additionally, DOTS agents		referred to as 'idle' time), 'idle-config'-related values must be
	MUST automatically switch to the other configuration upon a change in		followed). Additionally, DOTS agents MUST automatically switch to
	the mitigation activity (e.g., if an attack mitigation is launched		the other configuration upon a change in the mitigation activity
	after an 'idle' time, the DOTS agent switches from 'idle-config' to		(e.g., if an attack mitigation is launched after an 'idle' time, the
	'mitigating-config'-related values).		DOTS agent switches from 'idle-config' to 'mitigating-config'-related
			values).
	CoAP Requests and responses are indicated for reliable delivery by		CoAP Requests and responses are indicated for reliable delivery by
	marking them as Confirmable messages. DOTS signal channel session		marking them as Confirmable messages. DOTS signal channel session
	configuration requests and responses are marked as Confirmable		configuration requests and responses are marked as Confirmable
	messages. As explained in Section 2.1 of [RFC7252], a Confirmable		messages. As explained in Section 2.1 of [RFC7252], a Confirmable
	message is retransmitted using a default timeout and exponential		message is retransmitted using a default timeout and exponential
	back-off between retransmissions, until the DOTS server sends an		back-off between retransmissions, until the DOTS server sends an
	Acknowledgement message (ACK) with the same Message ID conveyed from		Acknowledgement message (ACK) with the same Message ID conveyed from
	the DOTS client.		the DOTS client.
	skipping to change at page 75, line 13 ¶		skipping to change at page 75, line 13 ¶
	likely with the DOTS signal channel.		likely with the DOTS signal channel.
	The DOTS client has to establish a (D)TLS session with the DOTS		The DOTS client has to establish a (D)TLS session with the DOTS
	server during 'idle' time and share a PSK.		server during 'idle' time and share a PSK.
	During a DDoS attack, the DOTS client can use the (D)TLS session		During a DDoS attack, the DOTS client can use the (D)TLS session
	to convey the DOTS mitigation request message and, if there is no		to convey the DOTS mitigation request message and, if there is no
	response from the server after multiple retries, the DOTS client		response from the server after multiple retries, the DOTS client
	can resume the (D)TLS session in 0-RTT mode using PSK.		can resume the (D)TLS session in 0-RTT mode using PSK.
			DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to
			send early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping"
			as early data; such messages MUST be rejected by DOTS servers.
	Section 8 of [RFC8446] discusses some mechanisms to implement to		Section 8 of [RFC8446] discusses some mechanisms to implement to
	limit the impact of replay attacks on 0-RTT data. If the DOTS		limit the impact of replay attacks on 0-RTT data. If the DOTS
	server accepts 0-RTT, it MUST implement one of these mechanisms.		server accepts 0-RTT, it MUST implement one of these mechanisms to
	A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.		prevent replay at the TLS layer. A DOTS server can reject 0-RTT
			by sending a TLS HelloRetryRequest.
	The DOTS signal channel messages sent as early data by the DOTS		The DOTS signal channel messages sent as early data by the DOTS
	client are idempotent requests. As a reminder, Message ID		client are idempotent requests. As a reminder, the Message ID
	(Section 3 of [RFC7252]) is changed each time a new CoAP request		(Section 3 of [RFC7252]) is changed each time a new CoAP request
	is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized		is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized
	in each CoAP request. The DOTS server(s) can use Message ID and		in each CoAP request. The DOTS server(s) MUST use the Message ID
	Token in the DOTS signal channel message to detect replay of early		and the Token in the DOTS signal channel message to detect replay
	data, and accept 0-RTT data at most once. Furthermore, 'mid'		of early data at the application layer, and accept 0-RTT data at
	value is monotonically increased by the DOTS client for each		most once from the same DOTS client. This anti-replay defense
	mitigation request, attackers replaying mitigation requests with		requires sharing the Message ID and the Token in the 0-RTT data
	lower numeric 'mid' values and overlapping scopes with mitigation		between DOTS servers in the DOTS server domain. DOTS servers do
	requests having higher numeric 'mid' values will be rejected		not rely on transport coordinates to identify DOTS peers. As
	systematically by the DOTS server. Likewise, 'sid' value is		specified in Section 4.4.1, DOTS servers couple the DOTS signal
	monotonically increased by the DOTS client for each configuration		channel sessions using the DOTS client identity and optionally the
	session, attackers replaying configuration requests with lower		'cdid' parameter value. Furthermore, 'mid' value is monotonically
	numeric 'sid' values will be rejected by the DOTS server if it		increased by the DOTS client for each mitigation request,
	maintains a higher numeric 'sid' value for this DOTS client.		attackers replaying mitigation requests with lower numeric 'mid'
			values and overlapping scopes with mitigation requests having
			higher numeric 'mid' values will be rejected systematically by the
			DOTS server. Likewise, 'sid' value is monotonically increased by
			the DOTS client for each configuration request (Section 4.5.2),
			attackers replaying configuration requests with lower numeric
			'sid' values will be rejected by the DOTS server if it maintains a
			higher numeric 'sid' value for this DOTS client.
	Owing to the aforementioned protections, especially those afforded		Owing to the aforementioned protections, all DOTS signal channel
	by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446		requests are safe to transmit in TLS 1.3 as early data. Refer to
	anti-replay mechanisms, all DOTS signal channel requests are safe
	to transmit in TLS 1.3 as early data. Refer to
	[I-D.boucadair-dots-earlydata] for more details.		[I-D.boucadair-dots-earlydata] for more details.
	A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request		A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
	message exchange is shown in Figure 26.		message exchange is shown in Figure 26.
	DOTS Client DOTS Server		DOTS Client DOTS Server
	ClientHello		ClientHello
	(0-RTT DOTS signal message)		(0-RTT DOTS signal message)
	-------->		-------->
	skipping to change at page 81, line 11 ¶		skipping to change at page 81, line 11 ¶
	(Section 4.6 of [RFC8126]) and of the comprehension-optional range		(Section 4.6 of [RFC8126]) and of the comprehension-optional range
	(0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of		(0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of
	[RFC8126]).		[RFC8126]).
	Registration requests for the 0x4000 - 0x7FFF range are evaluated		Registration requests for the 0x4000 - 0x7FFF range are evaluated
	after a three-week review period on the dots-signal-reg-		after a three-week review period on the dots-signal-reg-
	review@ietf.org mailing list, on the advice of one or more		review@ietf.org mailing list, on the advice of one or more
	Designated Experts. However, to allow for the allocation of		Designated Experts. However, to allow for the allocation of
	values prior to publication, the Designated Experts may approve		values prior to publication, the Designated Experts may approve
	registration once they are satisfied that such a specification		registration once they are satisfied that such a specification
	will be published. Registration requests sent to the mailing list		will be published. New registration requests should be sent in
	for review should use an appropriate subject (e.g., "Request to		the form of an email to the review mailing list; the request
	register CBOR Key Value: example").		should use an appropriate subject (e.g., "Request to register CBOR
			Key Value for DOTS: example"). IANA will only accept new
			registrations from the Designated Experts, and will check that
			review was requested on the mailing list in accordance with these
			procedures.
	Within the review period, the Designated Experts will either		Within the review period, the Designated Experts will either
	approve or deny the registration request, communicating this		approve or deny the registration request, communicating this
	decision to the review list and IANA. Denials should include an		decision to the review list and IANA. Denials should include an
	explanation and, if applicable, suggestions as to how to make the		explanation and, if applicable, suggestions as to how to make the
	request successful. Registration requests that are undetermined		request successful. Registration requests that are undetermined
	for a period longer than 21 days can be brought to the IESG's		for a period longer than 21 days can be brought to the IESG's
	attention (using the iesg@ietf.org mailing list) for resolution.		attention (using the iesg@ietf.org mailing list) for resolution.
	Criteria that should be applied by the Designated Experts includes		Criteria that should be applied by the Designated Experts includes
	skipping to change at page 90, line 48 ¶		skipping to change at page 90, line 48 ¶
	domain, DOTS gateways located in the client-domain SHOULD NOT reveal		domain, DOTS gateways located in the client-domain SHOULD NOT reveal
	the identification information that pertains to internal DOTS clients		the identification information that pertains to internal DOTS clients
	(e.g., source IP address, client's hostname) unless explicitly		(e.g., source IP address, client's hostname) unless explicitly
	configured to do so.		configured to do so.
	DOTS servers MUST verify that requesting DOTS clients are entitled to		DOTS servers MUST verify that requesting DOTS clients are entitled to
	trigger actions on a given IP prefix. That is, only actions on IP		trigger actions on a given IP prefix. That is, only actions on IP
	resources that belong to the DOTS client' domain MUST be authorized		resources that belong to the DOTS client' domain MUST be authorized
	by a DOTS server. The exact mechanism for the DOTS servers to		by a DOTS server. The exact mechanism for the DOTS servers to
	validate that the target prefixes are within the scope of the DOTS		validate that the target prefixes are within the scope of the DOTS
	client's domain is deployment-specific.		client domain is deployment-specific.
	The presence of DOTS gateways may lead to infinite forwarding loops,		The presence of DOTS gateways may lead to infinite forwarding loops,
	which is undesirable. To prevent and detect such loops, this		which is undesirable. To prevent and detect such loops, this
	document uses the Hop-Limit Option.		document uses the Hop-Limit Option.
	CoAP-specific security considerations are discussed in Section 11 of		CoAP-specific security considerations are discussed in Section 11 of
	[RFC7252], while CBOR-related security considerations are discussed		[RFC7252], while CBOR-related security considerations are discussed
	in Section 8 of [RFC7049].		in Section 8 of [RFC7049].
	11. Contributors		11. Contributors
	skipping to change at page 95, line 20 ¶		skipping to change at page 95, line 20 ¶
	[I-D.ietf-core-yang-cbor]		[I-D.ietf-core-yang-cbor]
	Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.		Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
	Minaburo, "CBOR Encoding of Data Modeled with YANG",		Minaburo, "CBOR Encoding of Data Modeled with YANG",
	draft-ietf-core-yang-cbor-07 (work in progress), September		draft-ietf-core-yang-cbor-07 (work in progress), September
	2018.		2018.
	[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-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P.,		Boucadair, M. and R. K, "Distributed Denial-of-Service
	Mortensen, A., and N. Teague, "Distributed Denial-of-		Open Threat Signaling (DOTS) Data Channel Specification",
	Service Open Threat Signaling (DOTS) Data Channel		draft-ietf-dots-data-channel-27 (work in progress),
	Specification", draft-ietf-dots-data-channel-25 (work in		February 2019.
	progress), January 2019.
	[I-D.ietf-dots-requirements]		[I-D.ietf-dots-requirements]
	Mortensen, A., K, R., and R. Moskowitz, "Distributed		Mortensen, A., K, R., and R. Moskowitz, "Distributed
	Denial of Service (DDoS) Open Threat Signaling		Denial of Service (DDoS) Open Threat Signaling
	Requirements", draft-ietf-dots-requirements-18 (work in		Requirements", draft-ietf-dots-requirements-20 (work in
	progress), February 2019.		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-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
End of changes. 17 change blocks.
	43 lines changed or deleted		57 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/