Diff: draft-ietf-dots-signal-channel-20.txt - draft-ietf-dots-signal-channel-21.txt

	< draft-ietf-dots-signal-channel-20.txt	draft-ietf-dots-signal-channel-21.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: November 29, 2018 Orange	Expires: January 18, 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.

	May 28, 2018	July 17, 2018

	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-20	draft-ietf-dots-signal-channel-21

	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 20 ¶	skipping to change at page 2, line 20 ¶
	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 November 29, 2018.	This Internet-Draft will expire on January 18, 2019.

	Copyright Notice	Copyright Notice

	Copyright (c) 2018 IETF Trust and the persons identified as the	Copyright (c) 2018 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 21, line 36 ¶	skipping to change at page 21, line 36 ¶
	},	},
	{	{
	"lower-port": 443	"lower-port": 443
	},	},
	{	{
	"lower-port": 8080	"lower-port": 8080
	}	}
	],	],
	"target-protocol": [	"target-protocol": [
	6	6

	]	],
		"lifetime": 3600
	}	}
	]	]
	}	}
	}	}

	Figure 7: PUT for DOTS Mitigation Request	Figure 7: PUT for DOTS Mitigation Request

	The corresponding CBOR encoding format is shown in Figure 8.	The corresponding CBOR encoding format is shown in Figure 8.

	A1 # map(1)	A1 # map(1)
	01 # unsigned(1)	01 # unsigned(1)
	A1 # map(1)	A1 # map(1)
	02 # unsigned(2)	02 # unsigned(2)
	81 # array(1)	81 # array(1)
	A3 # map(3)	A3 # map(3)

	18 23 # unsigned(35)	06 # unsigned(6)
	82 # array(2)	82 # array(2)
	74 # text(20)	74 # text(20)
	323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128"	323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128"
	74 # text(20)	74 # text(20)
	323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128"	323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128"

	05 # unsigned(5)	07 # unsigned(7)
	83 # array(3)	83 # array(3)
	A1 # map(1)	A1 # map(1)

	06 # unsigned(6)	08 # unsigned(8)
	18 50 # unsigned(80)	18 50 # unsigned(80)
	A1 # map(1)	A1 # map(1)

	06 # unsigned(6)	08 # unsigned(8)
	19 01BB # unsigned(443)	19 01BB # unsigned(443)
	A1 # map(1)	A1 # map(1)

	06 # unsigned(6)	08 # unsigned(8)
	19 1F90 # unsigned(8080)	19 1F90 # unsigned(8080)

	08 # unsigned(8)	0A # unsigned(10)
	81 # array(1)	81 # array(1)
	06 # unsigned(6)	06 # unsigned(6)

		0E # unsigned(14)
		A1 # map(1)
		19 0E10 # unsigned(3600)

	Figure 8: PUT for DOTS Mitigation Request (CBOR)	Figure 8: PUT for DOTS Mitigation Request (CBOR)

	In both DOTS signal and data channel sessions, the DOTS client MUST	In both DOTS signal and data channel sessions, the DOTS client MUST
	authenticate itself to the DOTS server (Section 8). The DOTS server	authenticate itself to the DOTS server (Section 8). The DOTS server
	may use the algorithm presented in Section 7 of [RFC7589] to derive	may use the algorithm presented in Section 7 of [RFC7589] to derive
	the DOTS client identity or username from the client certificate.	the DOTS client identity or username from the client certificate.
	The DOTS client identity allows the DOTS server to accept mitigation	The DOTS client identity allows the DOTS server to accept mitigation
	requests with scopes that the DOTS client is authorized to manage.	requests with scopes that the DOTS client is authorized to manage.


	skipping to change at page 47, line 52 ¶	skipping to change at page 47, line 52 ¶
	change occurs at the DOTS server side. For example, the new	change occurs at the DOTS server side. For example, the new
	configuration may instruct a DOTS client to cease heartbeats or	configuration may instruct a DOTS client to cease heartbeats or
	reduce heartbeat frequency.	reduce heartbeat frequency.

	It is NOT RECOMMENDED to return a Max-Age Option set to 0.	It is NOT RECOMMENDED to return a Max-Age Option set to 0.

	Returning a Max-Age Option set to 2**32-1 is equivalent to	Returning a Max-Age Option set to 2**32-1 is equivalent to
	associating an infinite lifetime with the configuration.	associating an infinite lifetime with the configuration.

	If a non-zero value of Max-Age Option is received by a DOTS client,	If a non-zero value of Max-Age Option is received by a DOTS client,

	it MUST issue a PUT request to refresh the configuration parameters	it MUST issue a GET request to refresh the configuration parameters
	for the signal channel before the expiry of the value enclosed in the	for the signal channel before the expiry of the value enclosed in the
	Max-Age option. When a DDoS attack is active, refresh requests MUST	Max-Age option. When a DDoS attack is active, refresh requests MUST
	NOT be sent by DOTS clients and the DOTS server MUST NOT terminate	NOT be sent by DOTS clients and the DOTS server MUST NOT terminate
	the (D)TLS session after the expiry of the value returned in Max-Age	the (D)TLS session after the expiry of the value returned in Max-Age
	Option.	Option.


	If Max-Age Option is not returned in a response, DOTS servers should	If Max-Age Option is not returned in a response, the DOTS client
	expect to receive PUT requests to refresh the configuration	initiates GET requests to refresh the configuration parameters each
	parameters each 60 seconds (Section 5.10.5 of [RFC7252]). To prevent	60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload,
	such overload, it is RECOMMENDED that DOTS servers return a Max-Age	it is RECOMMENDED that DOTS servers return a Max-Age Option in GET
	Option in GET responses. Considerations related to which value to	responses. Considerations related to which value to use and how such
	use and how such value is set, are implementation- and deployment-	value is set, are implementation- and deployment-specific.
	specific.

	If an Observe Option set to 0 is included in the configuration	If an Observe Option set to 0 is included in the configuration
	request, the DOTS server sends notifications of any configuration	request, the DOTS server sends notifications of any configuration
	change (Section 4.2 of [RFC7641]).	change (Section 4.2 of [RFC7641]).

	If a DOTS server detects that a misbehaving DOTS client does not	If a DOTS server detects that a misbehaving DOTS client does not
	contact the DOTS server after the expiry of Max-Age, in order to	contact the DOTS server after the expiry of Max-Age, in order to
	retrieve the signal channel configuration data, it MAY terminate the	retrieve the signal channel configuration data, it MAY terminate the
	(D)TLS session. A (D)TLS session is terminated by the receipt of an	(D)TLS session. A (D)TLS session is terminated by the receipt of an
	authenticated message that closes the connection (e.g., a fatal alert	authenticated message that closes the connection (e.g., a fatal alert

	skipping to change at page 82, line 9 ¶	skipping to change at page 82, line 9 ¶
	[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>.

	13.2. Informative References	13.2. Informative References

	[I-D.ietf-core-comi]	[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP	Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP

	Management Interface", draft-ietf-core-comi-02 (work in	Management Interface", draft-ietf-core-comi-03 (work in
	progress), December 2017.	progress), June 2018.

	[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-06 (work in progress), February	draft-ietf-core-yang-cbor-06 (work in progress), February
	2018.	2018.

	[I-D.ietf-dots-architecture]	[I-D.ietf-dots-architecture]
	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

	skipping to change at page 82, line 41 ¶	skipping to change at page 82, line 41 ¶

	[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-14 (work in	Requirements", draft-ietf-dots-requirements-14 (work in
	progress), February 2018.	progress), February 2018.

	[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-12 (work	Open Threat Signaling", draft-ietf-dots-use-cases-13 (work
	in progress), April 2018.	in progress), June 2018.

	[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-26 (work in progress), March	1.3", draft-ietf-tls-dtls13-28 (work in progress), July
	2018.	2018.

	[I-D.ietf-tls-tls13]	[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol	Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	March 2018.	March 2018.

	[proto_numbers]	[proto_numbers]
	"IANA, "Protocol Numbers"", 2011,	"IANA, "Protocol Numbers"", 2011,
	<http://www.iana.org/assignments/protocol-numbers>.	<http://www.iana.org/assignments/protocol-numbers>.

	skipping to change at page 85, line 34 ¶	skipping to change at page 85, line 34 ¶
	[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>.

	[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security	[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", RFC 7924,	(TLS) Cached Information Extension", RFC 7924,
	DOI 10.17487/RFC7924, July 2016,	DOI 10.17487/RFC7924, July 2016,
	<https://www.rfc-editor.org/info/rfc7924>.	<https://www.rfc-editor.org/info/rfc7924>.


	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.

	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,	RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.	<https://www.rfc-editor.org/info/rfc7951>.

	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.	March 2017, <https://www.rfc-editor.org/info/rfc8085>.

	[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:	[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
	Better Connectivity Using Concurrency", RFC 8305,	Better Connectivity Using Concurrency", RFC 8305,

End of changes. 18 change blocks.
	29 lines changed or deleted	27 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/