< draft-ietf-dots-signal-channel-39.txt		draft-ietf-dots-signal-channel-40.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: May 23, 2020 Orange		Expires: June 20, 2020 Orange
	P. Patil		P. Patil
	Cisco		Cisco
	A. Mortensen		A. Mortensen
	Arbor Networks, Inc.		Arbor Networks, Inc.
	N. Teague		N. Teague
	Iron Mountain Data Centers		Iron Mountain Data Centers
	November 20, 2019		December 18, 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-39		draft-ietf-dots-signal-channel-40
	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 May 23, 2020.		This Internet-Draft will expire on June 20, 2020.
	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 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37		4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37
	4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38		4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38
	4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40		4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40
	4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41		4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41
	4.5.1. Discover Configuration Parameters . . . . . . . . . . 43		4.5.1. Discover Configuration Parameters . . . . . . . . . . 43
	4.5.2. Convey DOTS Signal Channel Session Configuration . . 48		4.5.2. Convey DOTS Signal Channel Session Configuration . . 48
	4.5.3. Configuration Freshness and Notifications . . . . . . 53		4.5.3. Configuration Freshness and Notifications . . . . . . 53
	4.5.4. Delete DOTS Signal Channel Session Configuration . . 54		4.5.4. Delete DOTS Signal Channel Session Configuration . . 54
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57
	5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 59		5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 60
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 60		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 60
	5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 62		5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 62
	5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 66		5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 66
	6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 77		6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 77
	7. (D)TLS Protocol Profile and Performance Considerations . . . 79		7. (D)TLS Protocol Profile and Performance Considerations . . . 79
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 79		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 79
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 81		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 81
	7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 83		7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 83
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 83		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 85		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 86
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 85		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 86
	9.3. Media Type Registration . . . . . . . . . . . . . . . . . 85		9.3. Media Type Registration . . . . . . . . . . . . . . . . . 86
	9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 86		9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 87
	9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 86		9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 87
	9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 87		9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 88
	9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 87		9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 88
	9.6.1.1. Registration Template . . . . . . . . . . . . . . 87		9.6.1.1. Registration Template . . . . . . . . . . . . . . 88
	9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 88		9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 89
	9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 90		9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 91
	9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 91		9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 92
	9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 93		9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 94
	9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 93		9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 94
	9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 94		9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 95
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 95		10. Security Considerations . . . . . . . . . . . . . . . . . . . 96
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 97		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 98
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 98		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 99
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 98		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 99
	13.1. Normative References . . . . . . . . . . . . . . . . . . 98		13.1. Normative References . . . . . . . . . . . . . . . . . . 99
	13.2. Informative References . . . . . . . . . . . . . . . . . 102		13.2. Informative References . . . . . . . . . . . . . . . . . 102
	Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 106		Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 107
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107
	1. Introduction		1. Introduction
	A distributed denial-of-service (DDoS) attack is a distributed		A distributed denial-of-service (DDoS) attack is a distributed
	attempt to make machines or network resources unavailable to their		attempt to make machines or network resources unavailable to their
	intended users. In most cases, sufficient scale for an effective		intended users. In most cases, sufficient scale for an effective
	attack can be achieved by compromising enough end-hosts and using		attack can be achieved by compromising enough end-hosts and using
	those infected hosts to perpetrate and amplify the attack. The		those infected hosts to perpetrate and amplify the attack. The
	victim in this attack can be an application server, a host, a router,		victim in this attack can be an application server, a host, a router,
	a firewall, or an entire network.		a firewall, or an entire network.
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 24 ¶
	Likewise, it is out of scope of this document to specify the behavior		Likewise, it is out of scope of this document to specify the behavior
	to be followed by a DOTS client to send DOTS requests when multiple		to be followed by a DOTS client to send DOTS requests when multiple
	DOTS servers are provisioned (e.g., contact all DOTS servers, select		DOTS servers are provisioned (e.g., contact all DOTS servers, select
	one DOTS server among the list). Such behavior is specified in other		one DOTS server among the list). Such behavior is specified in other
	documents (e.g., [I-D.ietf-dots-multihoming]).		documents (e.g., [I-D.ietf-dots-multihoming]).
	4.2. CoAP URIs		4.2. CoAP URIs
	The DOTS server MUST support the use of the path-prefix of "/.well-		The DOTS server MUST support the use of the path-prefix of "/.well-
	known/" as defined in [RFC5785] and the registered name of "dots".		known/" as defined in [RFC8615] and the registered name of "dots".
	Each DOTS operation is indicated by a path-suffix that indicates the		Each DOTS operation is indicated by a path-suffix that indicates the
	intended operation. The operation path (Table 1) is appended to the		intended operation. The operation path (Table 1) is appended to the
	path-prefix to form the URI used with a CoAP request to perform the		path-prefix to form the URI used with a CoAP request to perform the
	desired DOTS operation.		desired DOTS operation.
	+-----------------------+----------------+-------------+		+-----------------------+----------------+-------------+
	| Operation | Operation Path | Details |		| Operation | Operation Path | Details |
	+-----------------------+----------------+-------------+		+-----------------------+----------------+-------------+
	| Mitigation | /mitigate | Section 4.4 |		| Mitigation | /mitigate | Section 4.4 |
	+-----------------------+----------------+-------------+		+-----------------------+----------------+-------------+
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	DOTS agents MUST NOT send more than one UDP datagram per round-trip		DOTS agents MUST NOT send more than one UDP datagram per round-trip
	time (RTT) to the peer DOTS agent on average following the data		time (RTT) to the peer DOTS agent on average following the data
	transmission guidelines discussed in Section 3.1.3 of [RFC8085].		transmission guidelines discussed in Section 3.1.3 of [RFC8085].
	Requests marked by the DOTS client as Non-confirmable messages are		Requests marked by the DOTS client as Non-confirmable messages are
	sent at regular intervals until a response is received from the DOTS		sent at regular intervals until a response is received from the DOTS
	server. If the DOTS client cannot maintain an RTT estimate, it MUST		server. If the DOTS client cannot maintain an RTT estimate, it MUST
	NOT send more than one Non-confirmable request every 3 seconds, and		NOT send more than one Non-confirmable request every 3 seconds, and
	SHOULD use an even less aggressive rate whenever possible (case 2 in		SHOULD use an even less aggressive rate whenever possible (case 2 in
	Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed		Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed
	because of other congestion control checks. Typically, mitigation		because of checks on probing rate (Section 4.7 of [RFC7252]).
	requests must be sent without checks on probing rate (Section 4.7 of
	[RFC7252]).
	JSON encoding of YANG modelled data [RFC7951] is used to illustrate		JSON encoding of YANG modelled data [RFC7951] is used to illustrate
	the various methods defined in the following sub-sections. Also, the		the various methods defined in the following sub-sections. Also, the
	examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and		examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and
	9.6.5.		9.6.5.
	4.4.1. Request Mitigation		4.4.1. Request Mitigation
	When a DOTS client requires mitigation for some reason, the DOTS		When a DOTS client requires mitigation for some reason, the DOTS
	client uses the CoAP PUT method to send a mitigation request to its		client uses the CoAP PUT method to send a mitigation request to its
	skipping to change at page 58, line 28 ¶		skipping to change at page 58, line 28 ¶
	receiving heartbeat probes from peer DOTS clients. As a reminder, it		receiving heartbeat probes from peer DOTS clients. As a reminder, it
	is the responsibility of DOTS clients to ensure that on-path		is the responsibility of DOTS clients to ensure that on-path
	translators/firewalls are maintaining a binding so that the same		translators/firewalls are maintaining a binding so that the same
	external IP address and/or port number is retained for the DOTS		external IP address and/or port number is retained for the DOTS
	signal channel session.		signal channel session.
	Under normal traffic conditions (i.e., no attack is ongoing), if a		Under normal traffic conditions (i.e., no attack is ongoing), if a
	DOTS agent does not receive any response from the peer DOTS agent for		DOTS agent does not receive any response from the peer DOTS agent for
	'missing-hb-allowed' number of consecutive heartbeat messages, it		'missing-hb-allowed' number of consecutive heartbeat messages, it
	concludes that the DOTS signal channel session is disconnected. The		concludes that the DOTS signal channel session is disconnected. The
	DOTS client MUST then try to resume the (D)TLS session.		DOTS client MUST then try to re-establish the DOTS signal channel
			session, preferably by resuming the (D)TLS session.
			Note: If a new DOTS signal channel session cannot be established,
			the DOTS client SHOULD NOT retry to establish the DOTS signal
			channel session more frequently than every 300 seconds (5 minutes)
			and MUST NOT retry more frequently than every 60 seconds (1
			minute). It is recommended that DOTS clients support means to
			alert administrators about the failure to establish a (D)TLS
			session.
	In case of a massive DDoS attack that saturates the incoming link(s)		In case of a massive DDoS attack that saturates the incoming link(s)
	to the DOTS client, all traffic from the DOTS server to the DOTS		to the DOTS client, all traffic from the DOTS server to the DOTS
	client will likely be dropped, although the DOTS server receives		client will likely be dropped, although the DOTS server receives
	heartbeat requests in addition to DOTS messages sent by the DOTS		heartbeat requests in addition to DOTS messages sent by the DOTS
	client. In this scenario, DOTS clients MUST behave differently to		client. In this scenario, DOTS clients MUST behave differently to
	handle message transmission and DOTS signal channel session		handle message transmission and DOTS signal channel session
	liveliness during link saturation:		liveliness during link saturation:
	The DOTS client MUST NOT consider the DOTS signal channel session		The DOTS client MUST NOT consider the DOTS signal channel session
	terminated even after a maximum 'missing-hb-allowed' threshold is		terminated even after a maximum 'missing-hb-allowed' threshold is
	reached. The DOTS client SHOULD keep on using the current DOTS		reached. The DOTS client SHOULD keep on using the current DOTS
	signal channel session to send heartbeat requests over it, so that		signal channel session to send heartbeat requests over it, so that
	the DOTS server knows the DOTS client has not disconnected the		the DOTS server knows the DOTS client has not disconnected the
	DOTS signal channel session.		DOTS signal channel session.
	After the maximum 'missing-hb-allowed' threshold is reached, the		After the maximum 'missing-hb-allowed' threshold is reached, the
	DOTS client SHOULD try to resume the (D)TLS session. The DOTS		DOTS client SHOULD try to establish a new DOTS signal channel
	client SHOULD send mitigation requests over the current DOTS		session. The DOTS client SHOULD send mitigation requests over the
	signal channel session, and in parallel, for example, try to		current DOTS signal channel session and, in parallel, send the
	resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to		mitigation requests over the new DOTS signal channel session.
	piggyback the mitigation request in the ClientHello message.		This may be handled, for example, by resumption of the (D)TLS
			session or using 0-RTT mode in DTLS 1.3 to piggyback the
			mitigation request in the ClientHello message.
	As soon as the link is no longer saturated, if traffic from the		As soon as the link is no longer saturated, if traffic from the
	DOTS server reaches the DOTS client over the current DOTS signal		DOTS server reaches the DOTS client over the current DOTS signal
	channel session, the DOTS client can stop (D)TLS session		channel session, the DOTS client can stop the new DOTS signal
	resumption or if (D)TLS session resumption is successful then		channel session attempt or if a new DOTS signal channel session is
	disconnect the current DOTS signal channel session.		successful then disconnect the current DOTS signal channel
			session.
	If the DOTS server receives traffic from the peer DOTS client (e.g.,		If the DOTS server receives traffic from the peer DOTS client (e.g.,
	peer DOTS client initiated heartbeats) but maximum 'missing-hb-		peer DOTS client initiated heartbeats) but maximum 'missing-hb-
	allowed' threshold is reached, the DOTS server MUST NOT consider the		allowed' threshold is reached, the DOTS server MUST NOT consider the
	DOTS signal channel session disconnected. The DOTS server MUST keep		DOTS signal channel session disconnected. The DOTS server MUST keep
	on using the current DOTS signal channel session so that the DOTS		on using the current DOTS signal channel session so that the DOTS
	client can send mitigation requests over the current DOTS signal		client can send mitigation requests over the current DOTS signal
	channel session. In this case, the DOTS server can identify the DOTS		channel session. In this case, the DOTS server can identify the DOTS
	client is under attack and the inbound link to the DOTS client		client is under attack and the inbound link to the DOTS client
	(domain) is saturated. Furthermore, if the DOTS server does not		(domain) is saturated. Furthermore, if the DOTS server does not
	skipping to change at page 59, line 40 ¶		skipping to change at page 60, line 8 ¶
	In DOTS over TCP, the sender of a DOTS heartbeat message has to allow		In DOTS over TCP, the sender of a DOTS heartbeat message has to allow
	up to 'heartbeat-interval' seconds when waiting for a heartbeat		up to 'heartbeat-interval' seconds when waiting for a heartbeat
	reply. When a failure is detected by a DOTS client, it proceeds with		reply. When a failure is detected by a DOTS client, it proceeds with
	the session recovery following the same approach as the one used for		the session recovery following the same approach as the one used for
	unreliable transports.		unreliable transports.
	5. DOTS Signal Channel YANG Modules		5. DOTS Signal Channel YANG Modules
	This document defines a YANG [RFC7950] module for DOTS mitigation		This document defines a YANG [RFC7950] module for DOTS mitigation
	scope, DOTS signal channel session configuration data, and DOTS		scope, DOTS signal channel session configuration data, DOTS
	redirection signaling.		redirection signaling, and DOTS heartbeats.
	This YANG module (ietf-dots-signal-channel) defines the DOTS client		This YANG module (ietf-dots-signal-channel) defines the DOTS client
	interaction with the DOTS server as seen by the DOTS client. A DOTS		interaction with the DOTS server as seen by the DOTS client. A DOTS
	server is allowed to update the non-configurable 'ro' entities in the		server is allowed to update the non-configurable 'ro' entities in the
	responses. This YANG module is not intended to be used via NETCONF/		responses. This YANG module is not intended to be used via NETCONF/
	RESTCONF for DOTS server management purposes; such module is out of		RESTCONF for DOTS server management purposes; such module is out of
	the scope of this document. It serves only to provide a data model		the scope of this document. It serves only to provide a data model
	and encoding, but not a management data model.		and encoding, but not a management data model.
	A companion YANG module is defined to include a collection of types		A companion YANG module is defined to include a collection of types
	defined by IANA: "iana-dots-signal-channel" (Section 5.2).		defined by IANA: "iana-dots-signal-channel" (Section 5.2).
	5.1. Tree Structure		5.1. Tree Structure
	This document defines the YANG module "ietf-dots-signal-channel"		This document defines the YANG module "ietf-dots-signal-channel"
	(Section 5.3), which has the following tree structure. A DOTS signal		(Section 5.3), which has the following tree structure. A DOTS signal
	message can be a mitigation, a configuration, or a redirect message.		message can be a mitigation, a configuration, a redirect, or a
			heartbeat message.
	module: ietf-dots-signal-channel		module: ietf-dots-signal-channel
	+--rw dots-signal		+--rw dots-signal
	+--rw (message-type)?		+--rw (message-type)?
	+--:(mitigation-scope)		+--:(mitigation-scope)
	| +--rw scope* [cuid mid]		| +--rw scope* [cuid mid]
	| +--rw cdid? string		| +--rw cdid? string
	| +--rw cuid string		| +--rw cuid string
	| +--rw mid uint32		| +--rw mid uint32
	| +--rw target-prefix* inet:ip-prefix		| +--rw target-prefix* inet:ip-prefix
	skipping to change at page 85, line 25 ¶		skipping to change at page 86, line 23 ¶
	names-port-numbers.xhtml.		names-port-numbers.xhtml.
	The assignment of port number 4646 is strongly suggested, as 4646 is		The assignment of port number 4646 is strongly suggested, as 4646 is
	the ASCII decimal value for ".." (DOTS).		the ASCII decimal value for ".." (DOTS).
	9.2. Well-Known 'dots' URI		9.2. Well-Known 'dots' URI
	This document requests IANA to register the 'dots' well-known URI		This document requests IANA to register the 'dots' well-known URI
	(Table 5) in the Well-Known URIs registry		(Table 5) in the Well-Known URIs registry
	(https://www.iana.org/assignments/well-known-uris/well-known-		(https://www.iana.org/assignments/well-known-uris/well-known-
	uris.xhtml) as defined by [RFC5785]:		uris.xhtml) as defined by [RFC8615]:
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	| URI | Change | Specification | Related |		| URI | Change | Specification | Related |
	| suffix | controller | document(s) | information |		| suffix | controller | document(s) | information |
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	| dots | IETF | [RFCXXXX] | None |		| dots | IETF | [RFCXXXX] | None |
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	Table 5: 'dots' well-known URI		Table 5: 'dots' well-known URI
	skipping to change at page 98, line 33 ¶		skipping to change at page 99, line 33 ¶
	Kuehlewind, and Alissa Cooper for the review.		Kuehlewind, and Alissa Cooper for the review.
	Thanks to Carsten Bormann for his review of the DOTS heartbeat		Thanks to Carsten Bormann for his review of the DOTS heartbeat
	mechanism.		mechanism.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-core-hop-limit]		[I-D.ietf-core-hop-limit]
	Boucadair, M., K, R., and J. Shallow, "Constrained		Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
	Application Protocol (CoAP) Hop-Limit Option", draft-ietf-		Application Protocol (CoAP) Hop-Limit Option", draft-ietf-
	core-hop-limit-07 (work in progress), October 2019.		core-hop-limit-07 (work in progress), October 2019.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	skipping to change at page 99, line 39 ¶		skipping to change at page 100, line 39 ¶
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,
	DOI 10.17487/RFC5785, April 2010,
	<https://www.rfc-editor.org/info/rfc5785>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011,		DOI 10.17487/RFC6066, January 2011,
	<https://www.rfc-editor.org/info/rfc6066>.		<https://www.rfc-editor.org/info/rfc6066>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	skipping to change at page 102, line 5 ¶		skipping to change at page 102, line 43 ¶
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/info/rfc8323>.		<https://www.rfc-editor.org/info/rfc8323>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
			(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
			<https://www.rfc-editor.org/info/rfc8615>.
	13.2. Informative References		13.2. Informative References
	[I-D.boucadair-dots-earlydata]		[I-D.boucadair-dots-earlydata]
	Boucadair, M. and R. K, "Using Early Data in DOTS", draft-		Boucadair, M. and R. K, "Using Early Data in DOTS", draft-
	boucadair-dots-earlydata-00 (work in progress), January		boucadair-dots-earlydata-00 (work in progress), January
	2019.		2019.
	[I-D.ietf-core-comi]		[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.		Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
	Petrov, "CoAP Management Interface", draft-ietf-core-		Petrov, "CoAP Management Interface", draft-ietf-core-
	comi-08 (work in progress), September 2019.		comi-08 (work in progress), September 2019.
	[I-D.ietf-core-yang-cbor]		[I-D.ietf-core-yang-cbor]
	Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of		Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
	Data Modeled with YANG", draft-ietf-core-yang-cbor-11		Data Modeled with YANG", draft-ietf-core-yang-cbor-11
	(work in progress), September 2019.		(work in progress), September 2019.
	[I-D.ietf-dots-architecture]		[I-D.ietf-dots-architecture]
	Mortensen, A., K, R., Andreasen, F., Teague, N., and R.		Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
	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-14 (work in progress), May 2019.		architecture-14 (work in progress), May 2019.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and R. K, "Distributed Denial-of-Service		Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
	Open Threat Signaling (DOTS) Data Channel Specification",		Service Open Threat Signaling (DOTS) Data Channel
	draft-ietf-dots-data-channel-31 (work in progress), July		Specification", draft-ietf-dots-data-channel-31 (work in
	2019.		progress), July 2019.
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment		Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
	Considerations for Distributed-Denial-of-Service Open		Deployment Considerations for Distributed-Denial-of-
	Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02		Service Open Threat Signaling (DOTS)", draft-ietf-dots-
	(work in progress), July 2019.		multihoming-02 (work in progress), July 2019.
	[I-D.ietf-dots-server-discovery]		[I-D.ietf-dots-server-discovery]
	Boucadair, M. and R. K, "Distributed-Denial-of-Service		Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
	Open Threat Signaling (DOTS) Agent Discovery", draft-ietf-		Service Open Threat Signaling (DOTS) Agent Discovery",
	dots-server-discovery-05 (work in progress), August 2019.		draft-ietf-dots-server-discovery-06 (work in progress),
			November 2019.
	[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-20 (work in
	progress), September 2019.		progress), September 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
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-33 (work in progress), October		1.3", draft-ietf-tls-dtls13-34 (work in progress),
	2019.		November 2019.
	[IANA.CBOR.Tags]		[IANA.CBOR.Tags]
	IANA, "Concise Binary Object Representation (CBOR) Tags",		IANA, "Concise Binary Object Representation (CBOR) Tags",
	<http://www.iana.org/assignments/cbor-tags/cbor-		<http://www.iana.org/assignments/cbor-tags/cbor-
	tags.xhtml>.		tags.xhtml>.
	[IANA.CoAP.Content-Formats]		[IANA.CoAP.Content-Formats]
	IANA, "CoAP Content-Formats",		IANA, "CoAP Content-Formats",
	<http://www.iana.org/assignments/core-parameters/core-		<http://www.iana.org/assignments/core-parameters/core-
	parameters.xhtml#content-formats>.		parameters.xhtml#content-formats>.
End of changes. 23 change blocks.
	66 lines changed or deleted		77 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/