< draft-ietf-dots-signal-channel-15.txt		draft-ietf-dots-signal-channel-16.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: July 14, 2018 Orange		Expires: July 15, 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.
	January 10, 2018		January 11, 2018
	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-15		draft-ietf-dots-signal-channel-16
	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 July 14, 2018.		This Internet-Draft will expire on July 15, 2018.
	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 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions and Terminology . . . . . . . . . . . 5		2. Notational Conventions and Terminology . . . . . . . . . . . 5
	3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6		3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
	4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8		4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8
	4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8		4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8
	4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9		4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9
	4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10		4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10
	4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11		4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11
	4.4.2. Retrieve Information Related to a Mitigation . . . . 22		4.4.2. Retrieve Information Related to a Mitigation . . . . 24
	4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 31		4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 31
	4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 33		4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 33
	4.5. DOTS Signal Channel Session Configuration . . . . . . . . 34		4.5. DOTS Signal Channel Session Configuration . . . . . . . . 34
	4.5.1. Discover Configuration Parameters . . . . . . . . . . 36		4.5.1. Discover Configuration Parameters . . . . . . . . . . 36
	4.5.2. Convey DOTS Signal Channel Session Configuration . . 39		4.5.2. Convey DOTS Signal Channel Session Configuration . . 39
	4.5.3. Delete DOTS Signal Channel Session Configuration . . 45		4.5.3. Delete DOTS Signal Channel Session Configuration . . 45
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 46		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 46
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 47		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 47
	5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 49		5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 49
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 49		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 49
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	server can enable mitigation on behalf of the DOTS client by		server can enable mitigation on behalf of the DOTS client by
	communicating the DOTS client's request to the mitigator and relaying		communicating the DOTS client's request to the mitigator and relaying
	selected mitigator feedback to the requesting DOTS client.		selected mitigator feedback to the requesting DOTS client.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=xyz"		Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
			Uri-Path: "mitigation-id=123"
	Content-Type: "application/cbor"		Content-Type: "application/cbor"
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mitigation-id": integer,
	"target-prefix": [		"target-prefix": [
	"string"		"string"
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": integer,		"lower-port": integer,
	"upper-port": integer		"upper-port": integer
	}		}
	],		],
	"target-protocol": [		"target-protocol": [
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 20 ¶
	DOTS server, i.e., the CUID used by a DOTS client SHOULD NOT		DOTS server, i.e., the CUID used by a DOTS client SHOULD NOT
	change over time. Distinct CUIDs MAY be used per DOTS server.		change over time. Distinct CUIDs MAY be used per DOTS server.
	DOTS servers MUST treat CUIDs as opaque values and MUST only		DOTS servers MUST treat CUIDs as opaque values and MUST only
	compare CUIDs for equality. That is, DOTS servers must not		compare CUIDs for equality. That is, DOTS servers must not
	interpret CUIDs. DOTS servers MUST return 4.09 (Conflict) error		interpret CUIDs. DOTS servers MUST return 4.09 (Conflict) error
	code to a DOTS peer to notify that the CUID is already in-use by		code to a DOTS peer to notify that the CUID is already in-use by
	another DOTS client of the same domain. Upon receipt of that		another DOTS client of the same domain. Upon receipt of that
	error code, a new CUID MUST be generated by the DOTS peer.		error code, a new CUID MUST be generated by the DOTS peer.
			Client-domain DOTS gateways MUST handle CUID collision directly
			and it is RECOMMENDED that CUID collision is handled directly by
			server-domain DOTS gateways.
	Client-domain DOTS gateways MAY rewrite the CUIDs used by internal		Client-domain DOTS gateways MAY rewrite the CUIDs used by internal
	DOTS clients. Triggers for such rewriting are out of scope.		DOTS clients. Triggers for such rewriting are out of scope.
	This is a mandatory attribute.		This is a mandatory attribute.
	mitigation-id: Identifier for the mitigation request represented		mitigation-id: Identifier for the mitigation request represented
	with an integer. This identifier MUST be unique for each		with an integer. This identifier MUST be unique for each
	mitigation request bound to the DOTS client, i.e., the		mitigation request bound to the DOTS client, i.e., the
	'mitigation-id' parameter value in the mitigation request needs to		'mitigation-id' parameter value in the mitigation request needs to
	be unique relative to the 'mitigation-id' parameter values of		be unique relative to the 'mitigation-id' parameter values of
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	supplied to the DOTS server. That information is meant to assist the		supplied to the DOTS server. That information is meant to assist the
	DOTS server to enforce some policies. Figure 6 shows an example of a		DOTS server to enforce some policies. Figure 6 shows an example of a
	request relayed by a server-domain DOTS gateway.		request relayed by a server-domain DOTS gateway.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=xyz"		Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
			Uri-Path: "mitigation-id=123"
	Content-Type: "application/cbor"		Content-Type: "application/cbor"
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"client-domain-hash": "string",		"client-domain-hash": "string",
	"scope": [		"scope": [
	{		{
	"mitigation-id": integer,
	"target-prefix": [		"target-prefix": [
	"string"		"string"
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": integer,		"lower-port": integer,
	"upper-port": integer		"upper-port": integer
	}		}
	],		],
	"target-protocol": [		"target-protocol": [
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 11 ¶
	under attack (illustrated in JSON diagnostic notation). The presence		under attack (illustrated in JSON diagnostic notation). The presence
	of 'client-domain-hash' indicates that a server-domain DOTS gateway		of 'client-domain-hash' indicates that a server-domain DOTS gateway
	has modified the initial PUT request sent by the DOTS client.		has modified the initial PUT request sent by the DOTS client.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "www.example.com"		Uri-Host: "www.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "v1"		Uri-Path: "v1"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=xyz"		Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
			Uri-Path: "mitigation-id=123"
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw",		"client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw",
	"scope": [		"scope": [
	{		{
	"mitigation-id": 12332,
	"target-prefix": [		"target-prefix": [
	"2001:db8:6401::1/128",		"2001:db8:6401::1/128",
	"2001:db8:6401::2/128"		"2001:db8:6401::2/128"
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": 80		"lower-port": 80
	},		},
	{		{
	"lower-port": 443		"lower-port": 443
	skipping to change at page 20, line 13 ¶		skipping to change at page 20, line 13 ¶
	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)
	A2 # map(2)		A2 # map(2)
	18 24 # unsigned(36)		18 24 # unsigned(36)
	76 # text(22)		76 # text(22)
	647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw"		647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw"
	02 # unsigned(2)		02 # unsigned(2)
	81 # array(1)		81 # array(1)
	A4 # map(4)		A3 # map(3)
	03 # unsigned(3)
	19 302C # unsigned(12332)
	18 23 # unsigned(35)		18 23 # unsigned(35)
	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)		05 # unsigned(5)
	83 # array(3)		83 # array(3)
	A1 # map(1)		A1 # map(1)
	06 # unsigned(6)		06 # unsigned(6)
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 23 ¶
	using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx		using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx
	codes are some sort of invalid requests (client errors). COAP 5.xx		codes are some sort of invalid requests (client errors). COAP 5.xx
	codes are returned if the DOTS server has erred or is currently		codes are returned if the DOTS server has erred or is currently
	unavailable to provide mitigation in response to the mitigation		unavailable to provide mitigation in response to the mitigation
	request from the DOTS client.		request from the DOTS client.
	Figure 9 shows an example of a PUT request that is successfully		Figure 9 shows an example of a PUT request that is successfully
	processed by a DOTS server (i.e., CoAP 2.xx response codes).		processed by a DOTS server (i.e., CoAP 2.xx response codes).
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw",		"client-domain-hash": "dz6pHjaADkaFTbjr0JGBpw",
	"scope": [		"scope": [
	{		{
	"mitigation-id": 12332,		"mitigation-id": 12332,
	"lifetime": 3600		"lifetime": 3600
	}		}
	]		]
	}		}
	}		}
	skipping to change at page 22, line 16 ¶		skipping to change at page 22, line 16 ¶
	in the PUT request in its configuration data bound to that DOTS		in the PUT request in its configuration data bound to that DOTS
	client, it MAY update the mitigation request, and a 2.04 (Changed)		client, it MAY update the mitigation request, and a 2.04 (Changed)
	response is returned to indicate a successful update of the		response is returned to indicate a successful update of the
	mitigation request.		mitigation request.
	If the request is conflicting with an existing mitigation request		If the request is conflicting with an existing mitigation request
	from a different DOTS client, and the DOTS server decides to maintain		from a different DOTS client, and the DOTS server decides to maintain
	the conflicting mitigation request, the DOTS server returns 4.09		the conflicting mitigation request, the DOTS server returns 4.09
	(Conflict) [RFC8132] to the requesting DOTS client. The response		(Conflict) [RFC8132] to the requesting DOTS client. The response
	includes enough information for a DOTS client to recognize the source		includes enough information for a DOTS client to recognize the source
	of the conflict (refer to 'conflict-information' specified in		of the conflict as described below:
	Section 4.4.2).
			conflict-information: Indicates that a mitigation request is
			conflicting with another mitigation request(s) from other DOTS
			client(s). This optional attribute has the following structure:
			conflict-status: Indicates the status of a conflicting mitigation
			request. The following values are defined:
			1: DOTS server has detected conflicting mitigation requests
			from different DOTS clients. This mitigation request is
			currently inactive until the conflicts are resolved.
			Another mitigation request is active.
			2: DOTS server has detected conflicting mitigation requests
			from different DOTS clients. This mitigation request is
			currently active.
			3: DOTS server has detected conflicting mitigation requests
			from different DOTS clients. All conflicting mitigation
			requests are inactive.
			conflict-cause: Indicates the cause of the conflict. The
			following values are defined:
			1: Overlapping targets. 'conflict-scope' provides more details
			about the conflicting target clauses.
			2: Conflicts with an existing white list. This code is
			returned when the DDoS mitigation detects source addresses/
			prefixes in the white-listed ACLs are attacking the target.
			3: CUID Collision. This code is returned when a DOTS client
			uses a CUID that is already used by another DOTS client of
			the same domain. This code is an indication that the
			request has been rejected and a new request with a new CUID
			is to be re-sent by the DOTS client. Note that 'conflict-
			status', 'conflict-scope', and 'retry-timer' are not
			returned in the error response.
			conflict-scope: Indicates the conflict scope. It may include a
			list of IP addresses, a list of prefixes, a list of port
			numbers, a list of target protocols, a list of FQDNs, a list of
			URIs, a list of alias-names, or references to conflicting ACLs.
			retry-timer: Indicates, in seconds, the time after which the DOTS
			client may re-issue the same request. The DOTS server returns
			'retry-timer' only to DOTS client(s) for which a mitigation
			request is deactivated. Any retransmission of the same
			mitigation request before the expiry of this timer is likely to
			be rejected by the DOTS server for the same reasons.
			The retry-timer SHOULD be equal to the lifetime of the active
			mitigation request resulting in the deactivation of the
			conflicting mitigation request. The lifetime of the
			deactivated mitigation request will be updated to (retry-timer
			+ 45 seconds), so the DOTS client can refresh the deactivated
			mitigation request after retry-timer seconds before expiry of
			lifetime and check if the conflict is resolved.
	For a mitigation request to continue beyond the initial negotiated		For a mitigation request to continue beyond the initial negotiated
	lifetime, the DOTS client has to refresh the current mitigation		lifetime, the DOTS client has to refresh the current mitigation
	request by sending a new PUT request. This PUT request MUST use the		request by sending a new PUT request. This PUT request MUST use the
	same 'mitigation-id' value, and MUST repeat all the other parameters		same 'mitigation-id' value, and MUST repeat all the other parameters
	as sent in the original mitigation request apart from a possible		as sent in the original mitigation request apart from a possible
	change to the lifetime parameter value.		change to the lifetime parameter value.
	The DOTS gateway, which inserted a 'client-domain-hash' attribute in		The DOTS gateway, which inserted a 'client-domain-hash' attribute in
	a request, MUST strip the 'client-domain-hash' parameter in the		a request, MUST strip the 'client-domain-hash' parameter in the
	corresponding response before forwarding the response to the DOTS		corresponding response before forwarding the response to the DOTS
	client. If we consider the example depicted in Figure 9, the message		client. If we consider the example depicted in Figure 9, the message
	that will be relayed by the DOTS gateway is shown in Figure 10.		that will be relayed by the DOTS gateway is shown in Figure 10.
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mitigation-id": 12332,		"mitigation-id": 12332,
	"lifetime": 3600		"lifetime": 3600
	}		}
	]		]
	}		}
	}		}
	Figure 10: 2.xx Response Body Relayed by a DOTS Gateway		Figure 10: 2.xx Response Body Relayed by a DOTS Gateway
	skipping to change at page 23, line 40 ¶		skipping to change at page 24, line 49 ¶
	These two examples assume the default of "c=a"; that is, the DOTS		These two examples assume the default of "c=a"; that is, the DOTS
	client asks for all data to be reported by the DOTS server.		client asks for all data to be reported by the DOTS server.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Query: "cuid=xyz"		Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
	Observe : 0		Observe : 0
	Figure 11: GET to Retrieve all DOTS Mitigation Requests		Figure 11: GET to Retrieve all DOTS Mitigation Requests
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Query: "cuid=xyz"		Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
	Uri-Query: "mitigation-id=12332"		Uri-Query: "mitigation-id=12332"
	Observe : 0		Observe : 0
	Figure 12: GET to Retrieve a Specific DOTS Mitigation Request		Figure 12: GET to Retrieve a Specific DOTS Mitigation Request
	Figure 13 shows a response example of all active mitigation requests		Figure 13 shows a response example of all active mitigation requests
	associated with the DOTS client on the DOTS server and the mitigation		associated with the DOTS client on the DOTS server and the mitigation
	status of each mitigation request.		status of each mitigation request.
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mitigation-id": 12332,		"mitigation-id": 12332,
	"mitigation-start": 1507818434.00,		"mitigation-start": 1507818434.00,
	"target-prefix": [		"target-prefix": [
	"2001:db8:6401::1/128",		"2001:db8:6401::1/128",
	"2001:db8:6401::2/128"		"2001:db8:6401::2/128"
	],		],
	"target-protocol": [		"target-protocol": [
	17		17
	skipping to change at page 26, line 20 ¶		skipping to change at page 27, line 20 ¶
	lifetime: The remaining lifetime of the mitigation request, in		lifetime: The remaining lifetime of the mitigation request, in
	seconds.		seconds.
	This is a mandatory attribute.		This is a mandatory attribute.
	status: Status of attack mitigation. The various possible values of		status: Status of attack mitigation. The various possible values of
	'status' parameter are explained in Table 2.		'status' parameter are explained in Table 2.
	This is a mandatory attribute.		This is a mandatory attribute.
	conflict-information: Indicates that a mitigation request is
	conflicting with another mitigation request(s) from other DOTS
	client(s). This optional attribute has the following structure:
	conflict-status: Indicates the status of a conflicting mitigation
	request. The following values are defined:
	1: DOTS server has detected conflicting mitigation requests
	from different DOTS clients. This mitigation request is
	currently inactive until the conflicts are resolved.
	Another mitigation request is active.
	2: DOTS server has detected conflicting mitigation requests
	from different DOTS clients. This mitigation request is
	currently active.
	3: DOTS server has detected conflicting mitigation requests
	from different DOTS clients. All conflicting mitigation
	requests are inactive.
	conflict-cause: Indicates the cause of the conflict. The
	following values are defined:
	1: Overlapping targets. 'conflict-scope' provides more details
	about the conflicting target clauses.
	2: Conflicts with an existing white list. This code is
	returned when the DDoS mitigation detects source addresses/
	prefixes in the white-listed ACLs are attacking the target.
	3: CUID Collision. This code is returned when a DOTS client
	uses a CUID that is already used by another DOTS client of
	the same domain.
	conflict-scope Indicates the conflict scope. It may include a
	list of IP addresses, a list of prefixes, a list of port
	numbers, a list of target protocols, a list of FQDNs, a list of
	URIs, a list of alias-names, or references to conflicting ACLs.
	retry-timer Indicates, in seconds, the time after which the DOTS
	client may re-issue the same request. The DOTS server returns
	'retry-timer' only to DOTS client(s) for which a mitigation
	request is deactivated. Any retransmission of the same
	mitigation request before the expiry of this timer is likely to
	be rejected by the DOTS server for the same reasons.
	The retry-timer SHOULD be equal to the lifetime of the active
	mitigation request resulting in the deactivation of the
	conflicting mitigation request. The lifetime of the
	deactivated mitigation request will be updated to (retry-timer
	+ 45 seconds), so the DOTS client can refresh the deactivated
	mitigation request after retry-timer seconds before expiry of
	lifetime and check if the conflict is resolved.
	bytes-dropped: The total dropped byte count for the mitigation		bytes-dropped: The total dropped byte count for the mitigation
	request since the attack mitigation is triggered. The count wraps		request since the attack mitigation is triggered. The count wraps
	around when it reaches the maximum value of unsigned integer.		around when it reaches the maximum value of unsigned integer.
	This is an optional attribute.		This is an optional attribute.
	bps-dropped: The average number of dropped bytes per second for the		bps-dropped: The average number of dropped bytes per second for the
	mitigation request since the attack mitigation is triggered. This		mitigation request since the attack mitigation is triggered. This
	SHOULD be a five-minute average.		SHOULD be a five-minute average.
	skipping to change at page 32, line 11 ¶		skipping to change at page 32, line 11 ¶
	An example of an efficacy update message, which includes an If-Match		An example of an efficacy update message, which includes an If-Match
	option with an empty value, is depicted in Figure 15.		option with an empty value, is depicted in Figure 15.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=xyz"		Uri-Path: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
			Uri-Path: "mitigation-id=123"
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	If-Match:		If-Match:
	{		{
	"mitigation-scope": {		"ietf-dots-signal:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mitigation-id": integer,
	"target-prefix": [		"target-prefix": [
	"string"		"string"
	],		],
	"target-port-range": [		"target-port-range": [
	{		{
	"lower-port": integer,		"lower-port": integer,
	"upper-port": integer		"upper-port": integer
	}		}
	],		],
	"target-protocol": [		"target-protocol": [
	skipping to change at page 33, line 41 ¶		skipping to change at page 33, line 41 ¶
	The same considerations for manipulating 'client-domain-hash'		The same considerations for manipulating 'client-domain-hash'
	parameter by DOTS gateways, as specified in Section 4.4.1, MUST be		parameter by DOTS gateways, as specified in Section 4.4.1, MUST be
	followed for DELETE requests.		followed for DELETE requests.
	Header: DELETE (Code=0.04)		Header: DELETE (Code=0.04)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Query: "cuid=xyz"		Uri-Query: "cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example"
	Uri-Query: "mitigation-id=123"		Uri-Query: "mitigation-id=123"
	Figure 16: Withdraw a DOTS Mitigation		Figure 16: Withdraw a DOTS Mitigation
	If the request does not include a 'mitigation-id' parameter, the DOTS		If the request does not include a 'mitigation-id' parameter, the DOTS
	server MUST reply with a 4.00 (Bad Request).		server MUST reply with a 4.00 (Bad Request).
	Once the request is validated, the DOTS server immediately		Once the request is validated, the DOTS server immediately
	acknowledges a DOTS client's request to withdraw the DOTS signal		acknowledges a DOTS client's request to withdraw the DOTS signal
	using 2.02 (Deleted) response code with no response payload. A 2.02		using 2.02 (Deleted) response code with no response payload. A 2.02
	skipping to change at page 36, line 31 ¶		skipping to change at page 36, line 31 ¶
	Uri-Path: "config"		Uri-Path: "config"
	Figure 17: GET to Retrieve Configuration		Figure 17: GET to Retrieve Configuration
	The DOTS server in the 2.05 (Content) response conveys the current,		The DOTS server in the 2.05 (Content) response conveys the current,
	minimum, and maximum attribute values acceptable by the DOTS server		minimum, and maximum attribute values acceptable by the DOTS server
	(Figure 18).		(Figure 18).
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"signal-config": {		"ietf-dots-signal:signal-config": {
	"mitigating-config": {		"mitigating-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"current-value": integer,		"current-value": integer,
	"min-value": integer,		"min-value": integer,
	"max-value": integer		"max-value": integer
	},		},
	"missing-hb-allowed": {		"missing-hb-allowed": {
	"current-value": integer,		"current-value": integer,
	"min-value": integer,		"min-value": integer,
	"max-value": integer		"max-value": integer
	skipping to change at page 38, line 4 ¶		skipping to change at page 38, line 4 ¶
	Figure 18: GET Configuration Response Body		Figure 18: GET Configuration Response Body
	Figure 19 shows an example of acceptable and current configuration		Figure 19 shows an example of acceptable and current configuration
	parameters on a DOTS server for DOTS signal channel session		parameters on a DOTS server for DOTS signal channel session
	configuration. The same acceptable configuration is used during		configuration. The same acceptable configuration is used during
	attack and peace times.		attack and peace times.
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"signal-config": {		"ietf-dots-signal:signal-config": {
	"mitigating-config": {		"mitigating-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"current-value": 30,		"current-value": 30,
	"min-value": 15,		"min-value": 15,
	"max-value": 240		"max-value": 240
	},		},
	"missing-hb-allowed": {		"missing-hb-allowed": {
	"current-value": 5,		"current-value": 5,
	"min-value": 3,		"min-value": 3,
	"max-value": 9		"max-value": 9
	skipping to change at page 40, line 43 ¶		skipping to change at page 40, line 43 ¶
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "host"		Uri-Host: "host"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "version"		Uri-Path: "version"
	Uri-Path: "config"		Uri-Path: "config"
	Uri-Path: "session-id=123"		Uri-Path: "session-id=123"
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"signal-config": {		"ietf-dots-signal:signal-config": {
	"mitigating-config": {		"mitigating-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"current-value": integer		"current-value": integer
	},		},
	"missing-hb-allowed": {		"missing-hb-allowed": {
	"current-value": integer		"current-value": integer
	},		},
	"max-retransmit": {		"max-retransmit": {
	"current-value": integer		"current-value": integer
	},		},
	skipping to change at page 44, line 14 ¶		skipping to change at page 44, line 14 ¶
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "www.example.com"		Uri-Host: "www.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "v1"		Uri-Path: "v1"
	Uri-Path: "config"		Uri-Path: "config"
	Uri-Path: "session-id=123"		Uri-Path: "session-id=123"
	Content-Format: "application/cbor"		Content-Format: "application/cbor"
	{		{
	"signal-config": {		"ietf-dots-signal:signal-config": {
	"mitigating-config": {		"mitigating-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"current-value": 91		"current-value": 91
	},		},
	"missing-hb-allowed": {		"missing-hb-allowed": {
	"current-value": 3		"current-value": 3
	},		},
	"max-retransmit": {		"max-retransmit": {
	"current-value": 7		"current-value": 7
	},		},
	skipping to change at page 46, line 25 ¶		skipping to change at page 46, line 25 ¶
	The DOTS server can return the error response code 3.00 in response		The DOTS server can return the error response code 3.00 in response
	to a PUT request from the DOTS client or convey the error response		to a PUT request from the DOTS client or convey the error response
	code 3.00 in a unidirectional notification response from the DOTS		code 3.00 in a unidirectional notification response from the DOTS
	server.		server.
	The DOTS server in the error response conveys the alternate DOTS		The DOTS server in the error response conveys the alternate DOTS
	server's FQDN, and the alternate DOTS server's IP address(es) and		server's FQDN, and the alternate DOTS server's IP address(es) and
	time to live values in the CBOR body (Figure 23).		time to live values in the CBOR body (Figure 23).
	{		{
			"ietf-dots-signal:redirected-signal": {
	"alt-server": "string",		"alt-server": "string",
	"alt-server-record": [		"alt-server-record": [
	{		{
	"addr": "string",		"addr": "string",
	"ttl" : integer		"ttl" : integer
	}		}
	]		]
			}
	}		}
	Figure 23: Redirected Server Error Response Body		Figure 23: Redirected Server Error Response Body
	The parameters are described below:		The parameters are described below:
	alt-server: FQDN of an alternate DOTS server.		alt-server: FQDN of an alternate DOTS server.
	addr: IP address of an alternate DOTS server.		addr: IP address of an alternate DOTS server.
	ttl: Time to live (TTL) represented as an integer number of seconds.		ttl: Time to live (TTL) represented as an integer number of seconds.
	Figure 24 shows a 3.00 response example to convey the DOTS alternate		Figure 24 shows a 3.00 response example to convey the DOTS alternate
	server 'alt-server.example', its IP addresses 2001:db8:6401::1 and		server 'alt-server.example', its IP addresses 2001:db8:6401::1 and
	2001:db8:6401::2, and TTL values 3600 and 1800.		2001:db8:6401::2, and TTL values 3600 and 1800.
	{		{
			"ietf-dots-signal:redirected-signal": {
	"alt-server": "alt-server.example",		"alt-server": "alt-server.example",
	"alt-server-record": [		"alt-server-record": [
	{		{
	"ttl" : 3600,		"ttl" : 3600,
	"addr": "2001:db8:6401::1"		"addr": "2001:db8:6401::1"
	},		},
	{		{
	"ttl" : 1800,		"ttl" : 1800,
	"addr": "2001:db8:6401::2"		"addr": "2001:db8:6401::2"
	}		}
	]		]
			}
	}		}
	Figure 24: Example of Redirected Server Error Response Body		Figure 24: Example of Redirected Server Error Response Body
	When the DOTS client receives 3.00 response, it considers the current		When the DOTS client receives 3.00 response, it considers the current
	request as failed, but SHOULD try re-sending the request to the		request as failed, but SHOULD try re-sending the request to the
	alternate DOTS server. During a DDoS attack, the DNS server may be		alternate DOTS server. During a DDoS attack, the DNS server may be
	the target of another DDoS attack, alternate DOTS server's IP		the target of another DDoS attack, alternate DOTS server's IP
	addresses conveyed in the 3.00 response help the DOTS client skip DNS		addresses conveyed in the 3.00 response help the DOTS client skip DNS
	lookup of the alternate DOTS server. The DOTS client can then try to		lookup of the alternate DOTS server. The DOTS client can then try to
	skipping to change at page 52, line 43 ¶		skipping to change at page 52, line 43 ¶
	list target-port-range {		list target-port-range {
	key "lower-port upper-port";		key "lower-port upper-port";
	description		description
	"Port range. When only lower-port is		"Port range. When only lower-port is
	present, it represents a single port.";		present, it represents a single port.";
	leaf lower-port {		leaf lower-port {
	type inet:port-number;		type inet:port-number;
	mandatory true;		mandatory true;
	description "Lower port number.";		description
			"Lower port number of the port range.";
	}		}
	leaf upper-port {		leaf upper-port {
	type inet:port-number;		type inet:port-number;
	must ". >= ../lower-port" {		must ". >= ../lower-port" {
	error-message		error-message
	"The upper port number must be greater than		"The upper port number must be greater than
	or equal to lower port number.";		or equal to lower port number.";
	}		}
	description "Upper port number.";		description
			"Upper port number of the port range.";
	}		}
	}		}
	leaf-list target-protocol {		leaf-list target-protocol {
	type uint8;		type uint8;
	description		description
	"Identifies the target protocol number.		"Identifies the target protocol number.
	The value '0' means 'all protocols'.		The value '0' means 'all protocols'.
	skipping to change at page 53, line 34 ¶		skipping to change at page 53, line 37 ¶
	description "FQDN identifying the target.";		description "FQDN identifying the target.";
	}		}
	leaf-list target-uri {		leaf-list target-uri {
	type inet:uri;		type inet:uri;
	description "URI identifying the target.";		description "URI identifying the target.";
	}		}
	leaf-list alias-name {		leaf-list alias-name {
	type string;		type string;
	description "alias name";		description
			"An alias name that points to a resoucre.";
	}		}
	}		}
	grouping mitigation-scope {		grouping mitigation-scope {
	description		description
	"Specifies the scope of the mitigation request.";		"Specifies the scope of the mitigation request.";
	leaf client-domain-hash {		leaf client-domain-hash {
	type string;		type string;
	description		description
	skipping to change at page 58, line 44 ¶		skipping to change at page 58, line 48 ¶
	a DOTS client.";		a DOTS client.";
	}		}
	}		}
	}		}
	}		}
	leaf pkts-dropped {		leaf pkts-dropped {
	type yang:zero-based-counter64;		type yang:zero-based-counter64;
	config false;		config false;
	description		description
	"Number of dropped packets";		"Number of dropped packets.";
	}		}
	leaf bps-dropped {		leaf bps-dropped {
	type yang:zero-based-counter64;		type yang:zero-based-counter64;
	config false;		config false;
	description		description
	"The average number of dropped bytes per second for		"The average number of dropped bytes per second for
	the mitigation request since the attack		the mitigation request since the attack
	mitigation is triggered.";		mitigation is triggered.";
	}		}
	skipping to change at page 60, line 16 ¶		skipping to change at page 60, line 18 ¶
	description		description
	"DOTS agents regularly send heartbeats to each other		"DOTS agents regularly send heartbeats to each other
	after mutual authentication is successfully		after mutual authentication is successfully
	completed in order to keep the DOTS signal channel		completed in order to keep the DOTS signal channel
	open.";		open.";
	leaf max-value {		leaf max-value {
	type int16;		type int16;
	units "seconds";		units "seconds";
	description		description
	"Maximum acceptable value.";		"Maximum acceptable heartbeat-interval value.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel";		Signaling (DOTS) Signal Channel";
	}		}
	leaf min-value {		leaf min-value {
	type int16;		type int16;
	units "seconds";		units "seconds";
	description		description
	"Minimum acceptable value.";		"Minimum acceptable heartbeat-interval value.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel";		Signaling (DOTS) Signal Channel";
	}		}
	leaf current-value {		leaf current-value {
	type int16;		type int16;
	units "seconds";		units "seconds";
	default 30;		default 30;
	description		description
	"Current value.		"Current heartbeat-interval value.
	'0' means that heartbeat mechanism is deactivated.";		'0' means that heartbeat mechanism is deactivated.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel";		Signaling (DOTS) Signal Channel";
	}		}
	}		}
	container missing-hb-allowed {		container missing-hb-allowed {
	description		description
	skipping to change at page 65, line 50 ¶		skipping to change at page 66, line 4 ¶
	case signal-config {		case signal-config {
	description		description
	"Configuration message.";		"Configuration message.";
	uses signal-config;		uses signal-config;
	}		}
	case redirected-signal {		case redirected-signal {
	description		description
	"Redirected signaling.";		"Redirected signaling.";
	uses redirected-signal;		uses redirected-signal;
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	6. Mapping Parameters to CBOR		6. Mapping Parameters to CBOR
	All parameters in the payload of the DOTS signal channel MUST be		All parameters in the payload of the DOTS signal channel MUST be
	mapped to CBOR types as shown in Table 4 and are assigned an integer		mapped to CBOR types as shown in Table 4 and are assigned an integer
	key to save space. The recipient of the payload MAY reject the		key to save space. The recipient of the payload MAY reject the
	information if it is not suitably mapped.		information if it is not suitably mapped.
	+-----------------------+----------+--------------------+		+-----------------------+---------+--------------------+------------+
	| Parameter Name | CBOR Key | CBOR Major Type |		| Parameter Name | CBOR | CBOR Major Type | JSON Type |
	+-----------------------+----------+--------------------+		| | Key | | |
	| mitigation-scope | 1 | 5 (map) |		+-----------------------+---------+--------------------+------------+
	| scope | 2 | 5 (map) |		| mitigation-scope | 1 | 5 (map) | Object |
	| mitigation-id | 3 | 0 (unsigned) |		| scope | 2 | 4 (array) | Array |
	| acl-list | 4 | 4 |		| mitigation-id | 3 | 0 (unsigned) | Number |
	| target-port-range | 5 | 4 |		| acl-list | 4 | 4 (array) | Array |
	| lower-port | 6 | 0 |		| target-port-range | 5 | 4 (array) | Array |
	| upper-port | 7 | 0 |		| lower-port | 6 | 0 (unsigned) | Number |
	| target-protocol | 8 | 4 |		| upper-port | 7 | 0 (unsigned) | Number |
	| target-fqdn | 9 | 4 |		| target-protocol | 8 | 4 (array) | Array |
	| target-uri | 10 | 4 |		| | | 0 (unsigned) | Number |
	| alias-name | 11 | 4 |		| target-fqdn | 9 | 4 (array) | Array |
	| lifetime | 12 | 0 |		| | | 3 (text string) | String |
	| attack-status | 13 | 0 |		| target-uri | 10 | 4 (array) | Array |
	| signal-config | 14 | 5 (map) |		| | | 3 (text string) | String |
	| heartbeat-interval | 15 | 5 (map) |		| alias-name | 11 | 4 (array) | Array |
	| max-retransmit | 16 | 5 (map) |		| | | 3 (text string) | String |
	| ack-timeout | 17 | 5 (map) |		| lifetime | 12 | 0 (unsigned) | Number |
	| ack-random-factor | 18 | 5 (map) |		| attack-status | 13 | 0 (unsigned) | Number |
	| min-value | 19 | 0 |		| signal-config | 14 | 5 (map) | Object |
	| max-value | 20 | 0 |		| heartbeat-interval | 15 | 5 (map) | Object |
	| status | 21 | 0 |		| max-retransmit | 16 | 5 (map) | Object |
	| conflict-information | 22 | 5 (map) |		| ack-timeout | 17 | 5 (map) | Object |
	| conflict-status | 23 | 0 |		| ack-random-factor | 18 | 5 (map) | Object |
	| conflict-cause | 24 | 0 |		| min-value | 19 | 0 (unsigned) | Number |
	| retry-timer | 25 | 0 |		| max-value | 20 | 0 (unsigned) | Number |
	| bytes-dropped | 26 | 0 |		| status | 21 | 0 (unsigned) | Number |
	| bps-dropped | 27 | 0 |		| conflict-information | 22 | 5 (map) | Object |
	| pkts-dropped | 28 | 0 |		| conflict-status | 23 | 0 (unsigned) | Number |
	| pps-dropped | 29 | 0 |		| conflict-cause | 24 | 0 (unsigned) | Number |
	| session-id | 30 | 0 |		| retry-timer | 25 | 0 (unsigned) | Number |
	| trigger-mitigation | 31 | 7 (simple types) |		| bytes-dropped | 26 | 0 (unsigned) | String |
	| missing-hb-allowed | 32 | 5 (map) |		| bps-dropped | 27 | 0 (unsigned) | String |
	| current-value | 33 | 0 |		| pkts-dropped | 28 | 0 (unsigned) | String |
	| mitigation-start | 34 | 7 (floating-point) |		| pps-dropped | 29 | 0 (unsigned) | String |
	| target-prefix | 35 | 4 (array) |		| session-id | 30 | 0 (unsigned) | Number |
	| client-domain-hash | 36 | 3 |		| trigger-mitigation | 31 | 7 (simple type) | true/false |
	| alt-server | 37 | 3 |		| missing-hb-allowed | 32 | 5 (map) | Object |
	| alt-server-record | 38 | 4 |		| current-value | 33 | 0 (unsigned) | Number |
	| addr | 39 | 3 |		| mitigation-start | 34 | 7 (floating-point) | Number |
	| ttl | 40 | 0 |		| target-prefix | 35 | 4 (array) | Array |
	| conflict-scope | 41 | 5 (map) |		| | | 3 (text string) | String |
	| acl-name | 42 | 3 |		| client-domain-hash | 36 | 3 (text string) | String |
	| acl-type | 43 | 3 |		| alt-server | 37 | 3 (text string) | String |
	| config-interval | 44 | 0 |		| alt-server-record | 38 | 4 (array) | Array |
	| mitigating-config | 45 | 5 (map) |		| addr | 39 | 3 (text string) | String |
	| idle-config | 46 | 5 (map) |		| ttl | 40 | 0 (unsigned) | Number |
	| cuid | 47 | 3 |		| conflict-scope | 41 | 5 (map) | Object |
	| min-value-decimal | 48 | 7 |		| acl-name | 42 | 3 (text string) | String |
	| max-value-decimal | 49 | 7 |		| acl-type | 43 | 3 (text string) | String |
	| current-value-decimal | 50 | 7 |		| config-interval | 44 | 0 (unsigned) | Number |
	+-----------------------+----------+--------------------+		| mitigating-config | 45 | 5 (map) | Object |
			| idle-config | 46 | 5 (map) | Object |
			| cuid | 47 | 3 (text string) | String |
			| min-value-decimal | 48 | 7 (floating-point) | Number |
			| max-value-decimal | 49 | 7 (floating-point) | Number |
			| current-value-decimal | 50 | 7 (floating-point) | Number |
			+-----------------------+---------+--------------------+------------+
	Table 4: CBOR Mappings Used in DOTS Signal Channel Messages		Table 4: CBOR Mappings Used in DOTS Signal Channel Messages
	7. (D)TLS Protocol Profile and Performance Considerations		7. (D)TLS Protocol Profile and Performance Considerations
	7.1. (D)TLS Protocol Profile		7.1. (D)TLS Protocol Profile
	This section defines the (D)TLS protocol profile of DOTS signal		This section defines the (D)TLS protocol profile of DOTS signal
	channel over (D)TLS and DOTS data channel over TLS.		channel over (D)TLS and DOTS data channel over TLS.
	skipping to change at page 68, line 4 ¶		skipping to change at page 68, line 12 ¶
	server, and connects to its configured DOTS server, the server may		server, and connects to its configured DOTS server, the server may
	present it with a PKIX certificate. In order to ensure proper		present it with a PKIX certificate. In order to ensure proper
	authentication, a DOTS client MUST verify the entire certification		authentication, a DOTS client MUST verify the entire certification
	path per [RFC5280]. The DOTS client additionally uses [RFC6125]		path per [RFC5280]. The DOTS client additionally uses [RFC6125]
	validation techniques to compare the domain name with the certificate		validation techniques to compare the domain name with the certificate
	provided.		provided.
	A key challenge to deploying DOTS is the provisioning of DOTS		A key challenge to deploying DOTS is the provisioning of DOTS
	clients, including the distribution of keying material to DOTS		clients, including the distribution of keying material to DOTS
	clients to enable the required mutual authentication of DOTS agents.		clients to enable the required mutual authentication of DOTS agents.
	EST defines a method of certificate enrollment by which domains		EST defines a method of certificate enrollment by which domains
	operating DOTS servers may provide DOTS clients with all the		operating DOTS servers may provide DOTS clients with all the
	necessary cryptographic keying material, including a private key and		necessary cryptographic keying material, including a private key and
	a certificate to authenticate themselves. One deployment option is		a certificate to authenticate themselves. One deployment option is
	DOTS clients behave as EST clients for certificate enrollment from an		DOTS clients behave as EST clients for certificate enrollment from an
	EST server provisioned by the mitigation provider. This document		EST server provisioned by the mitigation provider. This document
	does not specify which EST mechanism the DOTS client uses to achieve		does not specify which EST mechanism the DOTS client uses to achieve
	initial enrollment.		initial enrollment.
	The Server Name Indication (SNI) extension [RFC6066] defines a		The Server Name Indication (SNI) extension [RFC6066] defines a
	mechanism for a client to tell a (D)TLS server the name of the server		mechanism for a client to tell a (D)TLS server the name of the server
	it wants to contact. This is a useful extension for hosting		it wants to contact. This is a useful extension for hosting
	environments where multiple virtual servers are reachable over a		environments where multiple virtual servers are reachable over a
	single IP address. The DOTS client may or may not know if it is		single IP address. The DOTS client may or may not know if it is
	interacting with a DOTS server in the hosting environment, so the		interacting with a DOTS server in a virtual server hosting
	DOTS client SHOULD include the DOTS server FQDN in the SNI extension.		environment, so the DOTS client SHOULD include the DOTS server FQDN
			in the SNI extension.
	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 DTLS record replay detection (Section 3.3 of [RFC6347]) to protect		o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect
	against replay attacks.		against replay attacks.
	o (D)TLS session resumption without server-side state [RFC5077] to		o (D)TLS session resumption without server-side state [RFC5077] to
	resume session and convey the DOTS signal.		resume session and convey the DOTS signal.
	skipping to change at page 74, line 15 ¶		skipping to change at page 74, line 15 ¶
	9.4.2. Initial Registry Contents		9.4.2. Initial Registry Contents
	o Parameter Name: mitigation-scope		o Parameter Name: mitigation-scope
	o CBOR Key Value: 1		o CBOR Key Value: 1
	o CBOR Major Type: 5		o CBOR Major Type: 5
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): this document		o Specification Document(s): this document
	o Parameter Name: scope		o Parameter Name: scope
	o CBOR Key Value: 2		o CBOR Key Value: 2
	o CBOR Major Type: 5		o CBOR Major Type: 4
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): this document		o Specification Document(s): this document
	o Parameter Name: mitigation-id		o Parameter Name: mitigation-id
	o CBOR Key Value: 3		o CBOR Key Value: 3
	o CBOR Major Type: 0		o CBOR Major Type: 0
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): this document		o Specification Document(s): this document
	o Parameter Name: acl-list		o Parameter Name: acl-list
End of changes. 49 change blocks.
	152 lines changed or deleted		171 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/