< draft-ietf-dots-signal-channel-07.txt		draft-ietf-dots-signal-channel-08.txt >
	DOTS T. Reddy		DOTS T. Reddy
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair		Intended status: Standards Track M. Boucadair
	Expires: May 16, 2018 Orange		Expires: May 27, 2018 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.
	November 12, 2017		November 23, 2017
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal		Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel		Channel
	draft-ietf-dots-signal-channel-07		draft-ietf-dots-signal-channel-08
	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. A companion		traffic mitigation on behalf of the requesting client. A companion
	document defines the DOTS data channel, a separate reliable		document defines the DOTS data channel, a separate reliable
	communication layer for DOTS management and configuration.		communication layer for DOTS management and configuration.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 16, 2018.		This Internet-Draft will expire on May 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	5.4.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 25		5.4.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 25
	5.4.4. Efficacy Update from DOTS Client . . . . . . . . . . 30		5.4.4. Efficacy Update from DOTS Client . . . . . . . . . . 30
	5.5. DOTS Signal Channel Session Configuration . . . . . . . . 32		5.5. DOTS Signal Channel Session Configuration . . . . . . . . 32
	5.5.1. Discover Configuration Parameters . . . . . . . . . . 33		5.5.1. Discover Configuration Parameters . . . . . . . . . . 33
	5.5.2. Convey DOTS Signal Channel Session Configuration . . 35		5.5.2. Convey DOTS Signal Channel Session Configuration . . 35
	5.5.3. Delete DOTS Signal Channel Session Configuration . . 39		5.5.3. Delete DOTS Signal Channel Session Configuration . . 39
	5.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 40		5.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 40
	5.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41		5.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41
	6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 42		6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 42
	7. (D)TLS Protocol Profile and Performance considerations . . . 43		7. (D)TLS Protocol Profile and Performance considerations . . . 43
	7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 44		7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 45
	8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 45		8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 45
	9. Mutual Authentication of DOTS Agents & Authorization of DOTS		9. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 48		10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 48
	10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 48		10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 48
	10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 48		10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 48
	10.4. DOTS signal channel CBOR Mappings Registry . . . . . . . 48		10.4. DOTS signal channel CBOR Mappings Registry . . . . . . . 48
	10.4.1. Registration Template . . . . . . . . . . . . . . . 49		10.4.1. Registration Template . . . . . . . . . . . . . . . 49
	10.4.2. Initial Registry Contents . . . . . . . . . . . . . 49		10.4.2. Initial Registry Contents . . . . . . . . . . . . . 49
	11. Implementation Status . . . . . . . . . . . . . . . . . . . . 54		11. Implementation Status . . . . . . . . . . . . . . . . . . . . 54
	11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 54		11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 54
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 55		12. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
	15.1. Normative References . . . . . . . . . . . . . . . . . . 56		15.1. Normative References . . . . . . . . . . . . . . . . . . 56
	15.2. Informative References . . . . . . . . . . . . . . . . . 57		15.2. Informative References . . . . . . . . . . . . . . . . . 58
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
	1. Introduction		1. Introduction
	A distributed denial-of-service (DDoS) attack is an attempt to make		A distributed denial-of-service (DDoS) attack is an attempt to make
	machines or network resources unavailable to their intended users.		machines or network resources unavailable to their intended users.
	In most cases, sufficient scale can be achieved by compromising		In most cases, sufficient scale can be achieved by compromising
	enough end-hosts and using those infected hosts to perpetrate and		enough end-hosts and using those infected hosts to perpetrate and
	amplify the attack. The victim in this attack can be an application		amplify the attack. The victim in this attack can be an application
	server, a host, a router, a firewall, or an entire network.		server, a host, a router, a firewall, or an entire network.
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 17 ¶
	uri: A list of Uniform Resource Identifiers (URI). This is an		uri: A list of Uniform Resource Identifiers (URI). This is an
	optional attribute.		optional attribute.
	alias-name: A list of aliases. Aliases can be created using the		alias-name: A list of aliases. Aliases can be created using the
	DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel])		DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel])
	or direct configuration, or other means and then used in		or direct configuration, or other means and then used in
	subsequent signal channel exchanges to refer more efficiently to		subsequent signal channel exchanges to refer more efficiently to
	the resources under attack. This is an optional attribute.		the resources under attack. This is an optional attribute.
	lifetime: Lifetime of the mitigation request in seconds. The		lifetime: Lifetime of the mitigation request in seconds. The
	default lifetime of a mitigation request is 3600 seconds (60		RECOMMENDED lifetime of a mitigation request is 3600 seconds (60
	minutes) -- this value was chosen to be long enough so that		minutes) -- this value was chosen to be long enough so that
	refreshing is not typically a burden on the DOTS client, while		refreshing is not typically a burden on the DOTS client, while
	expiring the request where the client has unexpectedly quit in a		expiring the request where the client has unexpectedly quit in a
	timely manner.		timely manner.
	A lifetime of negative one (-1) indicates indefinite lifetime for		A lifetime of negative one (-1) indicates indefinite lifetime for
	the mitigation request.		the mitigation request. A lifetime of 0 in the request is an
			invalid value.
	DOTS clients SHOULD include this parameter in their mitigation		DOTS clients MUST include this parameter in their mitigation
	requests. If no lifetime is supplied by a DOTS client, the DOTS		requests. Upon the expiry of this lifetime, and if the request is
	server uses the default lifetime value (3600 seconds). Upon the		not refreshed, the mitigation request is removed. The request can
	expiry of this lifetime, and if the request is not refreshed, the		be refreshed by sending the same request again. The server MAY
	mitigation request is removed. The request can be refreshed by		refuse indefinite lifetime, for policy reasons; the granted
	sending the same request again. The server MAY refuse indefinite		lifetime value is returned in the response. DOTS clients MUST be
	lifetime, for policy reasons; the granted lifetime value is		prepared to not be granted mitigations with indefinite lifetimes.
	returned in the response. DOTS clients MUST be prepared to not be		The server MUST always indicate the actual lifetime in the
	granted mitigations with indefinite lifetimes. The server MUST		response and the remaining lifetime in status messages sent to the
	always indicate the actual lifetime in the response and the		client. This is a mandatory attribute.
	remaining lifetime in status messages sent to the client. This is
	a mandatory parameter for responses.
	The CBOR key values for the parameters are defined in Section 6.		The CBOR key values for the parameters are defined in Section 6.
	Section 10 defines how the CBOR key values can be allocated to		Section 10 defines how the CBOR key values can be allocated to
	standards bodies and vendors.		standards bodies and vendors.
	FQDN and URI mitigation scopes may be thought of as a form of scope		FQDN and URI mitigation scopes may be thought of as a form of scope
	alias, in which the addresses to which the domain name or URI resolve		alias, in which the addresses to which the domain name or URI resolve
	represent the full scope of the mitigation.		represent the full scope of the mitigation.
	In the PUT request at least one of the attributes 'target-ip' or		In the PUT request at least one of the attributes 'target-ip' or
	'target-prefix' or 'fqdn' or 'uri 'or 'alias-name' MUST be present.		'target-prefix' or 'fqdn' or 'uri 'or 'alias-name' MUST be present.
	DOTS agents can safely ignore Vendor-Specific parameters they don't		If the attribute value is empty, then the attribute MUST NOT be
	understand.		present in the request. DOTS agents can safely ignore Vendor-
			Specific parameters they don't understand.
	The relative order of two mitigation requests from a DOTS client is		The relative order of two mitigation requests from a DOTS client is
	determined by comparing their respective 'mitigation-id' values. If		determined by comparing their respective 'mitigation-id' values. If
	two mitigation requests have overlapping mitigation scopes, the		two mitigation requests have overlapping mitigation scopes, the
	mitigation request with higher numeric 'mitigation-id' value will		mitigation request with higher numeric 'mitigation-id' value will
	override the mitigation request with a lower numeric 'mitigation-id'		override the mitigation request with a lower numeric 'mitigation-id'
	value. Two mitigation-ids are overlapping if there is a common IP		value. Two mitigation-ids from a DOTS client are overlapping if
	address, IP prefix, FQDN, URI, or alias-name. The overlapped lower		there is a common IP address, IP prefix, FQDN, URI, or alias-name.
	numeric 'mitigation-id' MUST be automatically deleted and no longer		To avoid maintaining a long list of overlapping mitigation requests
	available at the DOTS server.		from a DOTS client and avoid error-prone provisioning of mitigation
			requests from a DOTS client, the overlapped lower numeric
			'mitigation-id' MUST be automatically deleted and no longer available
			at the DOTS server.
	The Uri-Path option carries a major and minor version nomenclature to		The Uri-Path option carries a major and minor version nomenclature to
	manage versioning and DOTS signal channel in this specification uses		manage versioning and DOTS signal channel in this specification uses
	v1 major version.		v1 major version.
	If the DOTS client is using the certificate provisioned by the		If the DOTS client is using the certificate provisioned by the
	Enrollment over Secure Transport (EST) server [RFC6234] in the DOTS		Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS
	gateway-domain to authenticate itself to the DOTS gateway, then the		gateway-domain to authenticate itself to the DOTS gateway, then the
	'client-identifier' value can be the output of a cryptographic hash		'client-identifier' value can be the output of a cryptographic hash
	algorithm whose input is the DER-encoded ASN.1 representation of the		algorithm whose input is the DER-encoded ASN.1 representation of the
	Subject Public Key Info (SPKI) of an X.509 certificate. In this		Subject Public Key Info (SPKI) of an X.509 certificate. In this
	version of the specification, the cryptographic hash algorithm used		version of the specification, the cryptographic hash algorithm used
	is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm		is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm
	is truncated to 16 bytes; truncation is done by stripping off the		is truncated to 16 bytes; truncation is done by stripping off the
	final 16 bytes. The truncated output is base64url encoded. If the		final 16 bytes. The truncated output is base64url encoded. If the
	'client-identifier' value is already present in the mitigation		'client-identifier' value is already present in the mitigation
	request received from the DOTS client, the DOTS gateway MAY compute		request received from the DOTS client, the DOTS gateway MAY compute
	skipping to change at page 44, line 14 ¶		skipping to change at page 44, line 14 ¶
	There are known attacks on (D)TLS, such as machine-in-the-middle and		There are known attacks on (D)TLS, such as machine-in-the-middle and
	protocol downgrade. These are general attacks on (D)TLS and not		protocol downgrade. These are general attacks on (D)TLS and not
	specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for		specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for
	discussion of these security issues. DOTS agents MUST adhere to the		discussion of these security issues. DOTS agents MUST adhere to the
	(D)TLS implementation recommendations and security considerations of		(D)TLS implementation recommendations and security considerations of
	[RFC7525] except with respect to (D)TLS version. Since encryption of		[RFC7525] except with respect to (D)TLS version. Since encryption of
	DOTS using (D)TLS is virtually a green-field deployment DOTS agents		DOTS using (D)TLS is virtually a green-field deployment DOTS agents
	MUST implement only (D)TLS 1.2 or later.		MUST implement only (D)TLS 1.2 or later.
			When a DOTS client is configured with a domain name of the DOTS
			server, and connects to its configured DOTS server, the server may
			present it with a PKIX certificate. In order to ensure proper
			authentication, DOTS client MUST verify the entire certification path
			per [RFC5280]. The DOTS client additionaly uses [RFC6125] validation
			techniques to compare the domain name to the certificate provided.
			A key challenge to deploying DOTS is provisioning DOTS clients,
			including the distribution of keying material to DOTS clients to make
			possible the required mutual authentication of DOTS agents. This
			specification relies on EST to overcome this. EST defines a method
			of certificate enrollment by which domains operating DOTS servers may
			provision DOTS clients with all necessary cryptographic keying
			material, including a private key and certificate with which to
			authenticate itself. This document does not specify which EST
			mechanism the DOTS client uses to achieve initial enrollment.
	Implementations compliant with this profile MUST implement all of the		Implementations compliant with this profile MUST implement all of the
	following items:		following items:
	o DOTS agents MUST support DTLS record replay detection (Section 3.3		o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect
	of [RFC6347]) to protect against replay attacks.		against replay attacks.
	o DOTS client can use (D)TLS session resumption without server-side		o (D)TLS session resumption without server-side state [RFC5077] to
	state [RFC5077] to resume session and convey the DOTS signal.		resume session and convey the DOTS signal.
	o Raw public keys [RFC7250] which reduce the size of the		o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduce
	ServerHello, and can be used by servers that cannot obtain		the size of the ServerHello, and can be used by DOTS agents that
	certificates (e.g., DOTS gateways on private networks).		cannot obtain certificates (e.g., DOTS clients and DOTS gateways
			on private networks).
	Implementations compliant with this profile SHOULD implement all of		Implementations compliant with this profile SHOULD implement all of
	the following items to reduce the delay required to deliver a DOTS		the following items to reduce the delay required to deliver a DOTS
	signal:		signal:
	o TLS False Start [RFC7918] which reduces round-trips by allowing		o TLS False Start [RFC7918] which reduces round-trips by allowing
	the TLS second flight of messages (ChangeCipherSpec) to also		the TLS second flight of messages (ChangeCipherSpec) to also
	contain the DOTS signal.		contain the DOTS signal.
	o Cached Information Extension [RFC7924] which avoids transmitting		o Cached Information Extension [RFC7924] which avoids transmitting
	skipping to change at page 56, line 39 ¶		skipping to change at page 56, line 39 ¶
	Silverajan, B., and B. Raymor, "CoAP (Constrained		Silverajan, B., and B. Raymor, "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	draft-ietf-core-coap-tcp-tls-10 (work in progress),		draft-ietf-core-coap-tcp-tls-10 (work in progress),
	October 2017.		October 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
			Ciphersuites for Transport Layer Security (TLS)",
			RFC 4279, DOI 10.17487/RFC4279, December 2005,
			<https://www.rfc-editor.org/info/rfc4279>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(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.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
			<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	DOI 10.17487/RFC5785, April 2010,		DOI 10.17487/RFC5785, April 2010,
	<https://www.rfc-editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.		June 2010, <https://www.rfc-editor.org/info/rfc5925>.
			[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
			Verification of Domain-Based Application Service Identity
			within Internet Public Key Infrastructure Using X.509
			(PKIX) Certificates in the Context of Transport Layer
			Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
			2011, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
	skipping to change at page 58, line 16 ¶		skipping to change at page 58, line 34 ¶
	Mortensen, A., Andreasen, F., Reddy, T.,		Mortensen, A., Andreasen, F., Reddy, T.,
	christopher_gray3@cable.comcast.com, c., Compton, R., and		christopher_gray3@cable.comcast.com, c., Compton, R., and
	N. Teague, "Distributed-Denial-of-Service Open Threat		N. Teague, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-		Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-05 (work in progress), October 2017.		architecture-05 (work in progress), October 2017.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,		Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
	P., Mortensen, A., and N. Teague, "Distributed Denial-of-		P., Mortensen, A., and N. Teague, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel", draft-		Service Open Threat Signaling (DOTS) Data Channel", draft-
	ietf-dots-data-channel-06 (work in progress), October		ietf-dots-data-channel-07 (work in progress), November
	2017.		2017.
	[I-D.ietf-dots-requirements]		[I-D.ietf-dots-requirements]
	Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed		Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
	Denial of Service (DDoS) Open Threat Signaling		Denial of Service (DDoS) Open Threat Signaling
	Requirements", draft-ietf-dots-requirements-07 (work in		Requirements", draft-ietf-dots-requirements-07 (work in
	progress), October 2017.		progress), October 2017.
	[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.,
	skipping to change at page 60, line 18 ¶		skipping to change at page 60, line 32 ¶
	<https://www.rfc-editor.org/info/rfc7030>.		<https://www.rfc-editor.org/info/rfc7030>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,		Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
	<https://www.rfc-editor.org/info/rfc7413>.		<https://www.rfc-editor.org/info/rfc7413>.
			[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
			Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
			2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the		[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
	NETCONF Protocol over Transport Layer Security (TLS) with		NETCONF Protocol over Transport Layer Security (TLS) with
	Mutual X.509 Authentication", RFC 7589,		Mutual X.509 Authentication", RFC 7589,
	DOI 10.17487/RFC7589, June 2015,		DOI 10.17487/RFC7589, June 2015,
	<https://www.rfc-editor.org/info/rfc7589>.		<https://www.rfc-editor.org/info/rfc7589>.
	[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport		[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", RFC 7918,		Layer Security (TLS) False Start", RFC 7918,
	DOI 10.17487/RFC7918, August 2016,		DOI 10.17487/RFC7918, August 2016,
	<https://www.rfc-editor.org/info/rfc7918>.		<https://www.rfc-editor.org/info/rfc7918>.
End of changes. 21 change blocks.
	36 lines changed or deleted		79 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/