< draft-ietf-dots-signal-channel-22.txt		draft-ietf-dots-signal-channel-23.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: February 8, 2019 Orange		Expires: February 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.
	August 7, 2018		August 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-22		draft-ietf-dots-signal-channel-23
	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 February 8, 2019.		This Internet-Draft will expire on February 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 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. 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 . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . 27		4.4.2. Retrieve Information Related to a Mitigation . . . . 26
	4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 31		4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 30
	4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 34		4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 33
	4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 35		4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 34
	4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 37		4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 36
	4.5. DOTS Signal Channel Session Configuration . . . . . . . . 38		4.5. DOTS Signal Channel Session Configuration . . . . . . . . 37
	4.5.1. Discover Configuration Parameters . . . . . . . . . . 40		4.5.1. Discover Configuration Parameters . . . . . . . . . . 39
	4.5.2. Convey DOTS Signal Channel Session Configuration . . 44		4.5.2. Convey DOTS Signal Channel Session Configuration . . 43
	4.5.3. Configuration Freshness and Notifications . . . . . . 49		4.5.3. Configuration Freshness and Notifications . . . . . . 48
	4.5.4. Delete DOTS Signal Channel Session Configuration . . 50		4.5.4. Delete DOTS Signal Channel Session Configuration . . 49
	4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51		4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 50
	4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53		4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 52
	5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 54		5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 53
	5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54		5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 53
	5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 56		5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 55
	6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 70		6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 69
	7. (D)TLS Protocol Profile and Performance Considerations . . . 72		7. (D)TLS Protocol Profile and Performance Considerations . . . 71
	7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 72		7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 71
	7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74		7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 72
	7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 75		7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73
	8. Mutual Authentication of DOTS Agents & Authorization of DOTS		8. Mutual Authentication of DOTS Agents & Authorization of DOTS
	Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 76		Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
	9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 77		9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 76
	9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 77		9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 76
	9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 78		9.3. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76
	9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 78		9.3.1. Registration Template . . . . . . . . . . . . . . . . 77
	9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 78		9.3.2. Initial Registry Content . . . . . . . . . . . . . . 77
	9.5.1. Registration Template . . . . . . . . . . . . . . . . 79		9.4. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 78
	9.5.2. Initial Registry Content . . . . . . . . . . . . . . 79		10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
	9.6. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 80		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 81		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 82		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82		13.1. Normative References . . . . . . . . . . . . . . . . . . 80
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 82		13.2. Informative References . . . . . . . . . . . . . . . . . 82
	13.1. Normative References . . . . . . . . . . . . . . . . . . 82		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
	13.2. Informative References . . . . . . . . . . . . . . . . . 84
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
	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 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	data exchange mechanism supporting the DOTS signal channel.		data exchange mechanism supporting the DOTS signal channel.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	(D)TLS is used for statements that apply to both Transport Layer		(D)TLS is used for statements that apply to both Transport Layer
	Security [RFC5246] and Datagram Transport Layer Security [RFC6347].		Security [RFC5246][RFC8446] and Datagram Transport Layer Security
	Specific terms are used for any statement that applies to either		[RFC6347]. Specific terms are used for any statement that applies to
	protocol alone.		either protocol alone.
	The reader should be familiar with the terms defined in		The reader should be familiar with the terms defined in
	[I-D.ietf-dots-requirements].		[I-D.ietf-dots-requirements].
	The meaning of the symbols in YANG tree diagrams is defined in		The meaning of the symbols in YANG tree diagrams is defined in
	[RFC8340].		[RFC8340].
	3. Design Overview		3. Design Overview
	The DOTS signal channel is built on top of the Constrained		The DOTS signal channel is built on top of the Constrained
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	Once the signal channel is established, the DOTS agents periodically		Once the signal channel is established, the DOTS agents periodically
	send heartbeats to keep the channel active (Section 4.7). At any		send heartbeats to keep the channel active (Section 4.7). At any
	time, the DOTS client may send a mitigation request message to a DOTS		time, the DOTS client may send a mitigation request message to a DOTS
	server over the active channel. While mitigation is active because		server over the active channel. While mitigation is active because
	of the higher likelihood of packet loss during a DDoS attack, the		of the higher likelihood of packet loss during a DDoS attack, the
	DOTS server periodically sends status messages to the client,		DOTS server periodically sends status messages to the client,
	including basic mitigation feedback details. Mitigation remains		including basic mitigation feedback details. Mitigation remains
	active until the DOTS client explicitly terminates mitigation, or the		active until the DOTS client explicitly terminates mitigation, or the
	mitigation lifetime expires.		mitigation lifetime expires.
	DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS		DOTS signaling can happen with DTLS over UDP and TLS over TCP.
	[RFC5246] over TCP. Likewise, DOTS requests may be sent using IPv4		Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer
	or IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS		capabilities. A Happy Eyeballs procedure for DOTS signal channel is
	signal channel is specified in Section 4.3.		specified in Section 4.3.
	Messages exchanged between DOTS agents are serialized using Concise		Messages exchanged between DOTS agents are serialized using Concise
	Binary Object Representation (CBOR) [RFC7049], a binary encoding		Binary Object Representation (CBOR) [RFC7049], a binary encoding
	scheme designed for small code and message size. CBOR-encoded		scheme designed for small code and message size. CBOR-encoded
	payloads are used to carry signal channel-specific payload messages		payloads are used to carry signal channel-specific payload messages
	which convey request parameters and response information such as		which convey request parameters and response information such as
	errors. In order to allow the use of the same data models, [RFC7951]		errors. In order to allow the use of the same data models, [RFC7951]
	specifies the JSON encoding of YANG-modeled data. A similar effort		specifies the JSON encoding of YANG-modeled data. A similar effort
	for CBOR is defined in [I-D.ietf-core-yang-cbor].		for CBOR is defined in [I-D.ietf-core-yang-cbor].
	skipping to change at page 18, line 49 ¶		skipping to change at page 18, line 49 ¶
	This implies that first server-domain DOTS gateways MUST strip		This implies that first server-domain DOTS gateways MUST strip
	'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD		'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD
	support a configuration parameter to identify DOTS gateways that		support a configuration parameter to identify DOTS gateways that
	are trusted to supply 'cdid' attributes.		are trusted to supply 'cdid' attributes.
	Only single-valued 'cdid' are defined in this document.		Only single-valued 'cdid' are defined in this document.
	This is an optional Uri-Path. When present, 'cdid' MUST be		This is an optional Uri-Path. When present, 'cdid' MUST be
	positioned before 'cuid'.		positioned before 'cuid'.
	A DOTS gateway may add the following CoAP option:		A DOTS gateway MAY add the CoAP Hop-Limit Option
			[I-D.boucadair-core-hop-limit].
	hop-limit: This option (see Section 9.4) is used to detect and
	prevent infinite loops. This option is typically inserted by a
	DOTS gateway. Only one single instance of the option is allowed
	in a message.
	The length of the hop-limit option is 1 byte.
	The value of the hop-limit option is encoded as an unsigned
	integer (see Section 3.2 of [RFC7252]).
	Each intermediate DOTS agent involved in the handling of a DOTS
	message MUST decrement the hop-limit option value by 1 prior to
	forwarding upstream if this parameter exists. DOTS messages MUST
	NOT be forwarded if the hop-limit option is set to '0' after
	decrement. Messages that cannot be forwarded because of exhausted
	hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error
	message sent back to the DOTS peer. It is RECOMMENDED that DOTS
	clients and gateways support means to alert administrators about
	loop errors so that appropriate actions are undertaken.
	To ease debugging and troubleshooting, the DOTS gateway which
	detects a loop SHOULD include its information (e.g., server name,
	alias, IP address) in the diagnostic payload under the conditions
	detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS
	gateway involved in relaying a 5.06 (Hop Limit Reached) error
	message SHOULD prepend its own information in the diagnostic
	payload with a space character used as separator. Only one
	information per DOTS gateway MUST appear in the diagnostic
	payload. The ultimate DOTS gateway MAY remove the diagnostic
	payload before forwarding the 5.06 (Hop Limit Reached) error
	message to a DOTS client domain.
	The initial hop-limit value SHOULD be configurable. If no initial
	value is explicitly provided, the default initial hop-limit value
	of 16 MUST be used.
	Because forwarding errors may occur if inadequate hop-limit values
	are used, DOTS agents at the boundaries of an administrative
	domain MAY be instructed to rewrite the value of hop-limit carried
	in received messages (that is, ignore the value of hop-limit
	received in a message).
	This is an optional CoAP option.
	Because of the complexity to handle partial failure cases, this		Because of the complexity to handle partial failure cases, this
	specification does not allow for including multiple mitigation		specification does not allow for including multiple mitigation
	requests in the same PUT request. Concretely, a DOTS client MUST NOT		requests in the same PUT request. Concretely, a DOTS client MUST NOT
	include multiple 'scope' parameters in the same PUT request.		include multiple 'scope' parameters in the same PUT request.
	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 associated with the domain name or URI		alias, in which the addresses associated with the domain name or URI
	represent the full scope of the mitigation.		represent the full scope of the mitigation.
	skipping to change at page 22, line 5 ¶		skipping to change at page 21, line 5 ¶
	"lifetime": 3600		"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)
	06 # unsigned(6)		06 # unsigned(6)
	82 # array(2)		82 # array(2)
	74 # text(20)		74 # text(20)
	323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128"		323030313A6462383A363430313A3A312F313238
	74 # text(20)		74 # text(20)
	323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128"		323030313A6462383A363430313A3A322F313238
	07 # unsigned(7)		07 # unsigned(7)
	83 # array(3)		83 # array(3)
	A1 # map(1)		A1 # map(1)
	08 # unsigned(8)		08 # unsigned(8)
	18 50 # unsigned(80)		18 50 # unsigned(80)
	A1 # map(1)		A1 # map(1)
	08 # unsigned(8)		08 # unsigned(8)
	19 01BB # unsigned(443)		19 01BB # unsigned(443)
	A1 # map(1)		A1 # map(1)
	08 # unsigned(8)		08 # unsigned(8)
	19 1F90 # unsigned(8080)		19 1F90 # unsigned(8080)
	0A # unsigned(10)		0A # unsigned(10)
	81 # array(1)		81 # array(1)
	06 # unsigned(6)		06 # unsigned(6)
	0E # unsigned(14)		0E # unsigned(14)
	19 0E10 # unsigned(3600)		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 29, line 10 ¶		skipping to change at page 28, line 10 ¶
	Figure 12 shows a response example of all active mitigation requests		Figure 12 shows a response example of all active mitigation requests
	associated with the DOTS client as maintained by the DOTS server.		associated with the DOTS client as maintained by the DOTS server.
	The response indicates the mitigation status of each mitigation		The response indicates the mitigation status of each mitigation
	request.		request.
	{		{
	"ietf-dots-signal-channel:mitigation-scope": {		"ietf-dots-signal-channel:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mid": 12332,		"mid": 12332,
	"mitigation-start": 1507818434,		"mitigation-start": "1507818434",
	"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
	],		],
	"lifetime": 1800,		"lifetime": 1800,
	"status": 2,		"status": "attack-successfully-mitigated",
	"bytes-dropped": 134334555,		"bytes-dropped": "134334555",
	"bps-dropped": 43344,		"bps-dropped": "43344",
	"pkts-dropped": 333334444,		"pkts-dropped": "333334444",
	"pps-dropped": 432432		"pps-dropped": "432432"
	},		},
	{		{
	"mid": 12333,		"mid": 12333,
	"mitigation-start": 1507818393,		"mitigation-start": "1507818393",
	"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": [
	6		6
	],		],
	"lifetime": 1800,		"lifetime": 1800,
	"status": 3,		"status": "attack-stopped",
	"bytes-dropped": 0,		"bytes-dropped": "0",
	"bps-dropped": 0,		"bps-dropped": "0",
	"pkts-dropped": 0,		"pkts-dropped": "0",
	"pps-dropped": 0		"pps-dropped": "0"
	}		}
	]		]
	}		}
	}		}
	Figure 12: Response Body to a Get Request		Figure 12: Response Body to a GET Request
	The mitigation status parameters are described below:		The mitigation status parameters are described below:
	mitigation-start: Mitigation start time is expressed in seconds		mitigation-start: Mitigation start time is expressed in seconds
	relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of		relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of
	[RFC7049]). The CBOR encoding is modified so that the leading tag		[RFC7049]). The CBOR encoding is modified so that the leading tag
	1 (epoch-based date/time) MUST be omitted.		1 (epoch-based date/time) MUST be omitted.
	This is a mandatory attribute when an attack mitigation is		This is a mandatory attribute when an attack mitigation is
	skipping to change at page 31, line 9 ¶		skipping to change at page 30, line 9 ¶
	pps-dropped: The average number of dropped packets per second for		pps-dropped: The average number of dropped packets per second for
	the mitigation request since the attack mitigation is triggered.		the mitigation request since the attack mitigation is triggered.
	This SHOULD be a five-minute average.		This SHOULD be a five-minute average.
	This is an optional attribute.		This is an optional attribute.
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| Parameter | Description |		| Parameter | Description |
	| Value | |		| Value | |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 1 | Attack mitigation is in progress (e.g., changing the |		| 1 | Attack mitigation setup is in progress (e.g., |
	| | network path to redirect the inbound traffic to a |		| | changing the network path to redirect the inbound |
	| | DOTS mitigator). |		| | traffic to a DOTS mitigator). |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 2 | Attack is successfully mitigated (e.g., traffic is |		| 2 | Attack is being successfully mitigated (e.g., traffic |
	| | redirected to a DDoS mitigator and attack traffic is |		| | is redirected to a DDoS mitigator and attack traffic |
	| | dropped). |		| | is dropped). |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 3 | Attack has stopped and the DOTS client can withdraw |		| 3 | Attack has stopped and the DOTS client can withdraw |
	| | the mitigation request. This status code will be |		| | the mitigation request. This status code will be |
	| | transmitted for immediate mitigation requests till |		| | transmitted for immediate mitigation requests till |
	| | the mitigation is withdrawn or the lifetime expires. |		| | the mitigation is withdrawn or the lifetime expires. |
	| | For mitigation requests with pre-configured scopes |		| | For mitigation requests with pre-configured scopes |
	| | (i.e., 'trigger-mitigation' set to 'false'), this |		| | (i.e., 'trigger-mitigation' set to 'false'), this |
	| | status code will be transmitted 4 times and then |		| | status code will be transmitted 4 times and then |
	| | transition to "8". |		| | transition to "8". |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	skipping to change at page 43, line 20 ¶		skipping to change at page 42, line 20 ¶
	"max-value": 9,		"max-value": 9,
	"min-value": 3,		"min-value": 3,
	"current-value": 5		"current-value": 5
	},		},
	"max-retransmit": {		"max-retransmit": {
	"max-value": 15,		"max-value": 15,
	"min-value": 2,		"min-value": 2,
	"current-value": 3		"current-value": 3
	},		},
	"ack-timeout": {		"ack-timeout": {
	"max-value-decimal": 30.0,		"max-value-decimal": "30.0",
	"min-value-decimal": 1.0,		"min-value-decimal": "1.0",
	"current-value-decimal": 2.0		"current-value-decimal": "2.0"
	},		},
	"ack-random-factor": {		"ack-random-factor": {
	"max-value-decimal": 4.0,		"max-value-decimal": "4.0",
	"min-value-decimal": 1.1,		"min-value-decimal": "1.1",
	"current-value-decimal": 1.5		"current-value-decimal": "1.5"
	}		}
	},		},
	"idle-config": {		"idle-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"max-value": 240,		"max-value": 240,
	"min-value": 15,		"min-value": 15,
	"current-value": 30		"current-value": 30
	},		},
	"missing-hb-allowed": {		"missing-hb-allowed": {
	"max-value": 9,		"max-value": 9,
	"min-value": 3,		"min-value": 3,
	"current-value": 5		"current-value": 5
	},		},
	"max-retransmit": {		"max-retransmit": {
	"max-value": 15,		"max-value": 15,
	"min-value": 2,		"min-value": 2,
	"current-value": 3		"current-value": 3
	},		},
	"ack-timeout": {		"ack-timeout": {
	"max-value-decimal": 30.0,		"max-value-decimal": "30.0",
	"min-value-decimal": 1.0,		"min-value-decimal": "1.0",
	"current-value-decimal": 2.0		"current-value-decimal": "2.0"
	},		},
	"ack-random-factor": {		"ack-random-factor": {
	"max-value-decimal": 4.0,		"max-value-decimal": "4.0",
	"min-value-decimal": 1.1,		"min-value-decimal": "1.1",
	"current-value-decimal": 1.5		"current-value-decimal": "1.5"
	}		}
	}		}
	}		}
	}		}
	Figure 18: Example of a Configuration Response Body		Figure 18: Example of a Configuration Response Body
	4.5.2. Convey DOTS Signal Channel Session Configuration		4.5.2. Convey DOTS Signal Channel Session Configuration
	A PUT request is used to convey the configuration parameters for the		A PUT request is used to convey the configuration parameters for the
	skipping to change at page 48, line 26 ¶		skipping to change at page 47, line 26 ¶
	"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": 3		"current-value": 3
	},		},
	"ack-timeout": {		"ack-timeout": {
	"current-value-decimal": 2.0		"current-value-decimal": "2.0"
	},		},
	"ack-random-factor": {		"ack-random-factor": {
	"current-value-decimal": 1.5		"current-value-decimal": "1.5"
	}		}
	},		},
	"idle-config": {		"idle-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	"current-value": 0		"current-value": 0
	},		},
	"max-retransmit": {		"max-retransmit": {
	"current-value": 3		"current-value": 3
	},		},
	"ack-timeout": {		"ack-timeout": {
	"current-value-decimal": 2.0		"current-value-decimal": "2.0"
	},		},
	"ack-random-factor": {		"ack-random-factor": {
	"current-value-decimal": 1.5		"current-value-decimal": "1.5"
	}		}
	}		}
	}		}
	}		}
	Figure 20: PUT to Convey the Configuration Parameters		Figure 20: PUT to Convey the Configuration Parameters
	The DOTS server indicates the result of processing the PUT request		The DOTS server indicates the result of processing the PUT request
	using CoAP response codes:		using CoAP response codes:
	skipping to change at page 50, line 25 ¶		skipping to change at page 49, line 25 ¶
	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
	(Section 7.2 of [RFC5246])).		(Section 6 of [RFC8446])).
	4.5.4. Delete DOTS Signal Channel Session Configuration		4.5.4. Delete DOTS Signal Channel Session Configuration
	A DELETE request is used to delete the installed DOTS signal channel		A DELETE request is used to delete the installed DOTS signal channel
	session configuration data (Figure 21).		session configuration data (Figure 21).
	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"
	skipping to change at page 51, line 11 ¶		skipping to change at page 50, line 11 ¶
	Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request		Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request
	to set the configuration parameters to default values. Such a		to set the configuration parameters to default values. Such a
	request does not include any 'sid'.		request does not include any 'sid'.
	4.6. Redirected Signaling		4.6. Redirected Signaling
	Redirected DOTS signaling is discussed in detail in Section 3.2.2 of		Redirected DOTS signaling is discussed in detail in Section 3.2.2 of
	[I-D.ietf-dots-architecture].		[I-D.ietf-dots-architecture].
	If a DOTS server wants to redirect a DOTS client to an alternative		If a DOTS server wants to redirect a DOTS client to an alternative
	DOTS server for a signal session, then the response code 3.00		DOTS server for a signal session, then the response code 5.03
	(alternate server) will be returned in the response to the DOTS		(Service Unavailable) will be returned in the response to the DOTS
	client.		client.
	The DOTS server can return the error response code 3.00 in response		The DOTS server can return the error response code 5.03 in response
	to a request from the DOTS client or convey the error response code		to a request from the DOTS client or convey the error response code
	3.00 in a unidirectional notification response from the DOTS server.		5.03 in a unidirectional notification response from the DOTS 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 22).		time to live values in the CBOR body (Figure 22).
	{		{
	"ietf-dots-signal-channel:redirected-signal": {		"ietf-dots-signal-channel:redirected-signal": {
	"alt-server": "string",		"alt-server": "string",
	"alt-server-record": [		"alt-server-record": [
	"string"		"string"
	],		]
	"alt-server-ttl": integer
	}		}
	Figure 22: Redirected Server Error Response Body		Figure 22: 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.
	This is a mandatory attribute.		This is a mandatory attribute.
	alt-server-record: A list of IP addresses of an alternate DOTS		alt-server-record: A list of IP addresses of an alternate DOTS
	server.		server.
	This is an optional attribute.		This is an optional attribute.
	alt-server-ttl: Time to live (TTL) of the alternate DOTS server,		The DOTS server returns the Time to live (TTL) of the alternate DOTS
	represented as an integer number of seconds. That is, the time		server in a Max-Age Option. That is, the time interval that the
	interval that the alternate DOTS server may be cached for use by a		alternate DOTS server may be cached for use by a DOTS client. A Max-
	DOTS client.		Age Option set to 2**32-1 is equivalent to receiving an infinite TTL.
			This value means that the alternate DOTS server is to be used until
	A value of negative one (-1) indicates indefinite TTL. This value		the alternate DOTS server redirects the traffic with another 5.03
	means that the alternate DOTS server is to be used until the		response which encloses an alternate server.
	alternate DOTS server redirects the traffic with another 3.00
	response.
	If no 'alt-server-ttl' is returned in a redirect response, this is
	equivalent to returning a 'alt-server-ttl' parameter set to '-1'.
	A 'alt-server-ttl' parameter set to '0' may be returned for
	redirecting mitigation requests. Such value means that the
	redirection applies only for the mitigation request in progress.
	Returning short 'alt-server-ttl' may adversely impact DOTS clients
	on slow links. Returning short values should be avoided under
	such conditions.
	If the alternate DOTS server TTL has expired, the DOTS client MUST		A Max-Age Option set to '0' may be returned for redirecting
	use the DOTS server(s), that was provisioned using means discussed		mitigation requests. Such value means that the redirection applies
	in Section 4.1. This fall back mechanism is triggered immediately		only for the mitigation request in progress. Returning short TTL in
	upon expiry of the TTL, except when a DDoS attack is active.		a Max-Age Option may adversely impact DOTS clients on slow links.
			Returning short values should be avoided under such conditions.
	Requests issued by misbehaving DOTS clients which do not honor the		If the alternate DOTS server TTL has expired, the DOTS client MUST
	TTL or react to explicit re-direct messages can be rejected by		use the DOTS server(s), that was provisioned using means discussed in
	DOTS servers.		Section 4.1. This fall back mechanism is triggered immediately upon
			expiry of the TTL, except when a DDoS attack is active.
	This is an optional attribute.		Requests issued by misbehaving DOTS clients which do not honor the
			TTL conveyed in the Max-Age Option or react to explicit re-direct
			messages can be rejected by DOTS servers.
	Figure 23 shows a 3.00 response example to convey the DOTS alternate		Figure 23 shows a 5.03 response example to convey the DOTS alternate
	server 'alt-server.example', its IP addresses 2001:db8:6401::1 and		server 'alt-server.example' together with its IP addresses
	2001:db8:6401::2, and 'alt-server-ttl' value 3600.		2001:db8:6401::1 and 2001:db8:6401::2.
	{		{
	"ietf-dots-signal-channel:redirected-signal": {		"ietf-dots-signal-channel:redirected-signal": {
	"alt-server": "alt-server.example",		"alt-server": "alt-server.example",
	"alt-server-record": [		"alt-server-record": [
	"2001:db8:6401::1",		"2001:db8:6401::1",
	"2001:db8:6401::2"		"2001:db8:6401::2"
	],		]
	"alt-server-ttl": 3600
	}		}
	Figure 23: Example of Redirected Server Error Response Body		Figure 23: Example of Redirected Server Error Response Body
	When the DOTS client receives 3.00 response, it considers the current		When the DOTS client receives 5.03 response with an alternate server
	request as failed, but SHOULD try re-sending the request to the		included, it considers the current request as failed, but SHOULD try
	alternate DOTS server. During a DDoS attack, the DNS server may be		re-sending the request to the alternate DOTS server. During a DDoS
	the target of another DDoS attack, alternate DOTS server's IP		attack, the DNS server may be the target of another DDoS attack,
	addresses conveyed in the 3.00 response help the DOTS client skip DNS		alternate DOTS server's IP addresses conveyed in the 5.03 response
	lookup of the alternate DOTS server. The DOTS client can then try to		help the DOTS client skip DNS lookup of the alternate DOTS server.
	establish a UDP or a TCP session with the alternate DOTS server. The		The DOTS client can then try to establish a UDP or a TCP session with
	DOTS client MAY implement a method to construct IPv4-embedded IPv6		the alternate DOTS server. The DOTS client MAY implement a method to
	addresses [RFC6052]; this is required to handle the scenario where an		construct IPv4-embedded IPv6 addresses [RFC6052]; this is required to
	IPv6-only DOTS client communicates with an IPv4-only alternate DOTS		handle the scenario where an IPv6-only DOTS client communicates with
	server.		an IPv4-only alternate DOTS server.
	If the DOTS client has been redirected to a DOTS server to which it		If the DOTS client has been redirected to a DOTS server to which it
	has already communicated with within the last five (5) minutes, it		has already communicated with within the last five (5) minutes, it
	MUST ignore the redirection and try to contact other DOTS servers		MUST ignore the redirection and try to contact other DOTS servers
	listed in the local configuration or discovered using dynamic means		listed in the local configuration or discovered using dynamic means
	such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients		such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients
	support means to alert administrators about redirect loops.		support means to alert administrators about redirect loops.
	4.7. Heartbeat Mechanism		4.7. Heartbeat Mechanism
	skipping to change at page 56, line 44 ¶		skipping to change at page 55, line 34 ¶
	| | +--ro max-value-decimal? decimal64		| | +--ro max-value-decimal? decimal64
	| | +--ro min-value-decimal? decimal64		| | +--ro min-value-decimal? decimal64
	| | +--rw current-value-decimal? decimal64		| | +--rw current-value-decimal? decimal64
	| +--rw ack-random-factor		| +--rw ack-random-factor
	| +--ro max-value-decimal? decimal64		| +--ro max-value-decimal? decimal64
	| +--ro min-value-decimal? decimal64		| +--ro min-value-decimal? decimal64
	| +--rw current-value-decimal? decimal64		| +--rw current-value-decimal? decimal64
	+--:(redirected-signal)		+--:(redirected-signal)
	+--ro alt-server string		+--ro alt-server string
	+--ro alt-server-record* inet:ip-address		+--ro alt-server-record* inet:ip-address
	+--ro alt-server-ttl? int32
	5.2. YANG Module		5.2. YANG Module
	<CODE BEGINS> file "ietf-dots-signal-channel@2018-08-07.yang"		<CODE BEGINS> file "ietf-dots-signal-channel@2018-08-16.yang"
	module ietf-dots-signal-channel {		module ietf-dots-signal-channel {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
	prefix signal;		prefix signal;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	skipping to change at page 58, line 6 ¶		skipping to change at page 56, line 44 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2018-08-07 {		revision 2018-08-16 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification";		Signaling (DOTS) Signal Channel Specification";
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	skipping to change at page 61, line 4 ¶		skipping to change at page 59, line 42 ¶
	config false;		config false;
	description		description
	"Mitigation start time is represented in seconds		"Mitigation start time is represented in seconds
	relative to 1970-01-01T00:00:00Z in UTC time.";		relative to 1970-01-01T00:00:00Z in UTC time.";
	}		}
	leaf status {		leaf status {
	type enumeration {		type enumeration {
	enum "attack-mitigation-in-progress" {		enum "attack-mitigation-in-progress" {
	value 1;		value 1;
	description		description
	"Attack mitigation is in progress (e.g., changing		"Attack mitigation setup is in progress (e.g., changing
	the network path to re-route the inbound traffic		the network path to re-route the inbound traffic
	to DOTS mitigator).";		to DOTS mitigator).";
	}		}
	enum "attack-successfully-mitigated" {		enum "attack-successfully-mitigated" {
	value 2;		value 2;
	description		description
	"Attack is successfully mitigated (e.g., traffic		"Attack is being successfully mitigated (e.g., traffic
	is redirected to a DDoS mitigator and attack		is redirected to a DDoS mitigator and attack
	traffic is dropped or blackholed).";		traffic is dropped or blackholed).";
	}		}
	enum "attack-stopped" {		enum "attack-stopped" {
	value 3;		value 3;
	description		description
	"Attack has stopped and the DOTS client can		"Attack has stopped and the DOTS client can
	withdraw the mitigation request.";		withdraw the mitigation request.";
	}		}
	enum "attack-exceeded-capability" {		enum "attack-exceeded-capability" {
	value 4;		value 4;
	description		description
	skipping to change at page 69, line 14 ¶		skipping to change at page 68, line 4 ¶
	is active.";		is active.";
	uses config-parameters;		uses config-parameters;
	}		}
	container idle-config {		container idle-config {
	description		description
	"Configuration parameters to use when no mitigation		"Configuration parameters to use when no mitigation
	is active.";		is active.";
	uses config-parameters;		uses config-parameters;
	}		}
	}		}
	grouping redirected-signal {		grouping redirected-signal {
	description		description
	"Grouping for the redirected signaling.";		"Grouping for the redirected signaling.";
	leaf alt-server {		leaf alt-server {
	type string;		type string;
	config false;		config false;
	mandatory true;		mandatory true;
	description		description
	"FQDN of an alternate server.";		"FQDN of an alternate server.";
	}		}
	leaf-list alt-server-record {		leaf-list alt-server-record {
	type inet:ip-address;		type inet:ip-address;
	config false;		config false;
	description		description
	"List of records for the alternate server.";		"List of records for the alternate server.";
	}		}
	leaf alt-server-ttl {
	type int32;
	config false;
	description
	"TTL associated with alt-server records.
	A value of negative one (-1) indicates indefinite
	TTL. This value means that the alternate
	DOTS server is to be used until the alternate DOTS
	server redirects the traffic with another
	3.00 response.";
	}
	}		}
	/*		/*
	* Main Container for DOTS Signal Channel		* Main Container for DOTS Signal Channel
	*/		*/
	container dots-signal {		container dots-signal {
	description		description
	"Main container for DOTS signal message.		"Main container for DOTS signal message.
	skipping to change at page 72, line 21 ¶		skipping to change at page 70, line 47 ¶
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| idle-config | container | 44 | 5 map | Object |		| idle-config | container | 44 | 5 map | Object |
	| trigger-mitigation | boolean | 45 | 7 bits 20 | False |		| trigger-mitigation | boolean | 45 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| ietf-dots-signal-cha | | | | |		| ietf-dots-signal-cha | | | | |
	|nnel:redirected-signal| container | 46 | 5 map | Object |		|nnel:redirected-signal| container | 46 | 5 map | Object |
	| alt-server | string | 47 | 3 text string | String |		| alt-server | string | 47 | 3 text string | String |
	| alt-server-record | leaf-list | 48 | 4 array | Array |		| alt-server-record | leaf-list | 48 | 4 array | Array |
	| | inet: | | | |		| | inet: | | | |
	| | ip-address | | 3 text string | String |		| | ip-address | | 3 text string | String |
	| alt-server-ttl | int32 | 49 | 0 unsigned | Number |
	| | | | 1 negative | 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 73, line 32 ¶		skipping to change at page 72, line 8 ¶
	interacting with a DOTS server in a virtual server hosting		interacting with a DOTS server in a virtual server hosting
	environment, so the DOTS client SHOULD include the DOTS server FQDN		environment, so the DOTS client SHOULD include the DOTS server FQDN
	in the SNI extension.		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 DTLS session resumption without server-side state to resume
	resume session and convey the DOTS signal.		session and convey the DOTS signal.
	o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduces		o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduces
	the size of the ServerHello, and can be used by DOTS agents that		the size of the ServerHello, and can be used by DOTS agents that
	cannot obtain certificates.		cannot obtain certificates.
	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 channel message:		signal channel message:
	o TLS False Start [RFC7918] which reduces round-trips by allowing		o TLS False Start [RFC7918] which reduces round-trips by allowing
	skipping to change at page 74, line 7 ¶		skipping to change at page 72, line 32 ¶
	o Cached Information Extension [RFC7924] which avoids transmitting		o Cached Information Extension [RFC7924] which avoids transmitting
	the server's certificate and certificate chain if the client has		the server's certificate and certificate chain if the client has
	cached that information from a previous TLS handshake.		cached that information from a previous TLS handshake.
	o TCP Fast Open [RFC7413] can reduce the number of round-trips to		o TCP Fast Open [RFC7413] can reduce the number of round-trips to
	convey DOTS signal channel message.		convey DOTS signal channel message.
	7.2. (D)TLS 1.3 Considerations		7.2. (D)TLS 1.3 Considerations
	TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements		TLS 1.3 provides critical latency improvements for connection
	for connection establishment over TLS 1.2. The DTLS 1.3 protocol		establishment over TLS 1.2. The DTLS 1.3 protocol
	[I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides		[I-D.ietf-tls-dtls13] is based upon the TLS 1.3 protocol and provides
	equivalent security guarantees. (D)TLS 1.3 provides two basic		equivalent security guarantees. (D)TLS 1.3 provides two basic
	handshake modes the DOTS signal channel can take advantage of:		handshake modes the DOTS signal channel can take advantage of:
	o A full handshake mode in which a DOTS client can send a DOTS		o A full handshake mode in which a DOTS client can send a DOTS
	mitigation request message after one round trip and the DOTS		mitigation request message after one round trip and the DOTS
	server immediately responds with a DOTS mitigation response. This		server immediately responds with a DOTS mitigation response. This
	assumes no packet loss is experienced.		assumes no packet loss is experienced.
	o 0-RTT mode in which the DOTS client can authenticate itself and		o 0-RTT mode in which the DOTS client can authenticate itself and
	skipping to change at page 74, line 32 ¶		skipping to change at page 73, line 10 ¶
	likely with the DOTS signal channel.		likely with the DOTS signal channel.
	The DOTS client has to establish a (D)TLS session with the DOTS		The DOTS client has to establish a (D)TLS session with the DOTS
	server during peacetime and share a PSK.		server during peacetime and share a PSK.
	During a DDoS attack, the DOTS client can use the (D)TLS session		During a DDoS attack, the DOTS client can use the (D)TLS session
	to convey the DOTS mitigation request message and, if there is no		to convey the DOTS mitigation request message and, if there is no
	response from the server after multiple retries, the DOTS client		response from the server after multiple retries, the DOTS client
	can resume the (D)TLS session in 0-RTT mode using PSK.		can resume the (D)TLS session in 0-RTT mode using PSK.
	Section 8 of [I-D.ietf-tls-tls13] discusses some mechanisms to		Section 8 of [RFC8446] discusses some mechanisms to implement to
	implement to limit the impact of replay attacks on 0-RTT data. If		limit the impact of replay attacks on 0-RTT data. If the DOTS
	TLS1.3 is used, DOTS servers must implement one of these		server accepts 0-RTT, it MUST implement one of these mechanisms.
	mechanisms.		A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.
	A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request		A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
	message exchange is shown in Figure 24.		message exchange is shown in Figure 24.
	DOTS Client DOTS Server		DOTS Client DOTS Server
	ClientHello		ClientHello
	(Finished)		(Finished)
	(0-RTT DOTS signal message)		(0-RTT DOTS signal message)
	(end_of_early_data) -------->		(end_of_early_data) -------->
	skipping to change at page 77, line 24 ¶		skipping to change at page 76, line 8 ¶
	perform mutual authentication (e.g., using certificates). A DOTS		perform mutual authentication (e.g., using certificates). A DOTS
	server will only allow a DOTS gateway with a certificate for a		server will only allow a DOTS gateway with a certificate for a
	particular domain to request mitigation for that domain. In		particular domain to request mitigation for that domain. In
	reference to Figure 25, the DOTS server only allows the DOTS gateway		reference to Figure 25, the DOTS server only allows the DOTS gateway
	to request mitigation for 'example.com' domain and not for other		to request mitigation for 'example.com' domain and not for other
	domains.		domains.
	9. IANA Considerations		9. IANA Considerations
	This specification registers a service port (Section 9.1), a URI		This specification registers a service port (Section 9.1), a URI
	suffix in the Well-Known URIs registry (Section 9.2), a CoAP response		suffix in the Well-Known URIs registry (Section 9.2), and a YANG
	code (Section 9.3), a YANG module (Section 9.6). It also creates a		module (Section 9.4). It also creates a registry for mappings to
	registry for mappings to CBOR (Section 9.5).		CBOR (Section 9.3).
	9.1. DOTS Signal Channel UDP and TCP Port Number		9.1. DOTS Signal Channel UDP and TCP Port Number
	IANA is requested to assign the port number TBD to the DOTS signal		IANA is requested to assign the port number TBD to the DOTS signal
	channel protocol for both UDP and TCP from the "Service Name and		channel protocol for both UDP and TCP from the "Service Name and
	Transport Protocol Port Number Registry" available at		Transport Protocol Port Number Registry" available at
	https://www.iana.org/assignments/service-names-port-numbers/service-		https://www.iana.org/assignments/service-names-port-numbers/service-
	names-port-numbers.xhtml.		names-port-numbers.xhtml.
	The assignment of port number 4646 is strongly suggested, as 4646 is		The assignment of port number 4646 is strongly suggested, as 4646 is
	the ASCII decimal value for ".." (DOTS).		the ASCII decimal value for ".." (DOTS).
	9.2. Well-Known 'dots' URI		9.2. Well-Known 'dots' URI
	This document requests IANA to register the 'dots' well-known URI in		This document requests IANA to register the 'dots' well-known URI
	the Well-Known URIs registry (https://www.iana.org/assignments/well-		(Table 5) in the Well-Known URIs registry
	known-uris/well-known-uris.xhtml) as defined by [RFC5785]:		(https://www.iana.org/assignments/well-known-uris/well-known-
			uris.xhtml) as defined by [RFC5785]:
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	| URI | Change | Specification | Related |		| URI | Change | Specification | Related |
	| suffix | controller | document(s) | information |		| suffix | controller | document(s) | information |
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	| dots | IETF | [RFCXXXX] | None |		| dots | IETF | [RFCXXXX] | None |
	+----------+----------------+---------------------+-----------------+		+----------+----------------+---------------------+-----------------+
	Table 5: 'dots' well-known URI		Table 5: 'dots' well-known URI
	9.3. CoAP Response Code		9.3. DOTS Signal Channel CBOR Mappings Registry
	IANA is requested to add the following entries to the "CoAP Response
	Codes" sub-registry available at https://www.iana.org/assignments/
	core-parameters/core-parameters.xhtml#response-codes:
	+------+------------------+-----------+
	| Code | Description | Reference |
	+------+------------------+-----------+
	| 3.00 | Alternate Server | [RFCXXXX] |
	| 5.06 | Hop Limit Reached| [RFCXXXX] |
	+------+------------------+-----------+
	Table 6: CoAP Response Codes
	9.4. CoAP Option Number
	IANA is requested to add the following entry to the "CoAP Option
	Numbers" sub-registry available at https://www.iana.org/assignments/
	core-parameters/core-parameters.xhtml#option-numbers:
	+--------+------------------+-----------+
	| Number | Name | Reference |
	+--------+------------------+-----------+
	| 2 | Hop-Limit | [RFCXXXX] |
	+--------+------------------+-----------+
	Table 7: CoAP Option Number
	9.5. DOTS Signal Channel CBOR Mappings Registry
	The document requests IANA to create a new registry, entitled "DOTS		The document requests IANA to create a new registry, entitled "DOTS
	Signal Channel CBOR Mappings Registry". The structure of this		Signal Channel CBOR Mappings Registry". The structure of this
	registry is provided in Section 9.5.1.		registry is provided in Section 9.3.1.
	The registry is initially populated with the values in Section 9.5.2.		The registry is initially populated with the values in Table 6.
	Values from that registry MUST be assigned via Expert Review		Values from that registry MUST be assigned via Expert Review
	[RFC8126].		[RFC8126].
	9.5.1. Registration Template		9.3.1. Registration Template
	Parameter name:		Parameter name:
	Parameter name as used in the DOTS signal channel.		Parameter name as used in the DOTS signal channel.
	CBOR Key Value:		CBOR Key Value:
	Key value for the parameter. The key value MUST be an integer in		Key value for the parameter. The key value MUST be an integer in
	the 1-65535 range. The key values in the 32768-65535 range are		the 1-65535 range. The key values in the 32768-65535 range are
	assigned to Vendor-Specific parameters.		assigned to Vendor-Specific parameters.
	CBOR Major Type:		CBOR Major Type:
	skipping to change at page 79, line 29 ¶		skipping to change at page 77, line 29 ¶
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party. Other details (e.g., postal		name of the responsible party. Other details (e.g., postal
	address, email address, home page URI) may also be included.		address, email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	Reference to the document or documents that specify the parameter,		Reference to the document or documents that specify the parameter,
	preferably including URIs that can be used to retrieve copies of		preferably including URIs that can be used to retrieve copies of
	the documents. An indication of the relevant sections may also be		the documents. An indication of the relevant sections may also be
	included but is not required.		included but is not required.
	9.5.2. Initial Registry Content		9.3.2. Initial Registry Content
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	| Parameter Name | CBOR | CBOR | Change | Specification |		| Parameter Name | CBOR | CBOR | Change | Specification |
	| | Key | Major | Controller | Document(s) |		| | Key | Major | Controller | Document(s) |
	| | Value | Type | | |		| | Value | Type | | |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	| ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] |		| ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] |
	| nel:mitigation-scope | | | | |		| nel:mitigation-scope | | | | |
	| scope | 2 | 4 | IESG | [RFCXXXX] |		| scope | 2 | 4 | IESG | [RFCXXXX] |
	| cdid | 3 | 3 | IESG | [RFCXXXX] |		| cdid | 3 | 3 | IESG | [RFCXXXX] |
	skipping to change at page 80, line 39 ¶		skipping to change at page 78, line 39 ¶
	| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |		| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |
	| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |		| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |
	| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |		| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |
	| decimal | | | | |		| decimal | | | | |
	| idle-config | 44 | 5 | IESG | [RFCXXXX] |		| idle-config | 44 | 5 | IESG | [RFCXXXX] |
	| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |		| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
	| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |		| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
	| nel:redirected-signal| | | | |		| nel:redirected-signal| | | | |
	| alt-server | 47 | 3 | IESG | [RFCXXXX] |		| alt-server | 47 | 3 | IESG | [RFCXXXX] |
	| alt-server-record | 48 | 4 | IESG | [RFCXXXX] |		| alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
	| alt-server-ttl | 49 | 0/1 | IESG | [RFCXXXX] |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	Table 8: Initial DOTS Signal Channel CBOR Mappings Registry		Table 6: Initial DOTS Signal Channel CBOR Mappings Registry
	9.6. DOTS Signal Channel YANG Module		9.4. DOTS Signal Channel YANG Module
	This document requests IANA to register the following URI in the		This document requests IANA to register the following URI in the
	"IETF XML Registry" [RFC3688]:		"IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel		URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	This document requests IANA to register the following YANG module in		This document requests IANA to register the following YANG module in
	the "YANG Module Names" registry [RFC7950].		the "YANG Module Names" registry [RFC7950].
	skipping to change at page 82, line 9 ¶		skipping to change at page 80, line 9 ¶
	DOTS servers MUST verify that requesting DOTS clients are entitled to		DOTS servers MUST verify that requesting DOTS clients are entitled to
	trigger actions on a given IP prefix. That is, only actions on IP		trigger actions on a given IP prefix. That is, only actions on IP
	resources that belong to the DOTS client' domain MUST be authorized		resources that belong to the DOTS client' domain MUST be authorized
	by a DOTS server. The exact mechanism for the DOTS servers to		by a DOTS server. The exact mechanism for the DOTS servers to
	validate that the target prefixes are within the scope of the DOTS		validate that the target prefixes are within the scope of the DOTS
	client's domain is deployment-specific.		client's domain is deployment-specific.
	The presence of DOTS gateways may lead to infinite forwarding loops,		The presence of DOTS gateways may lead to infinite forwarding loops,
	which is undesirable. To prevent and detect such loops, this		which is undesirable. To prevent and detect such loops, this
	document specifies the 'hop-limit' option (Section 4.4.1).		document uses the Hop-Limit Option.
	CoAP-specific security considerations are discussed in Section 11 of		CoAP-specific security considerations are discussed in Section 11 of
	[RFC7252], while CBOR-related security considerations are discussed		[RFC7252], while CBOR-related security considerations are discussed
	in Section 8 of [RFC7049].		in Section 8 of [RFC7049].
	11. Contributors		11. Contributors
	The following individuals have contributed to this document:		The following individuals have contributed to this document:
	o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust		o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
	skipping to change at page 82, line 36 ¶		skipping to change at page 80, line 36 ¶
	o Dan Wing, Email: dwing-ietf@fuggles.com		o Dan Wing, Email: dwing-ietf@fuggles.com
	12. Acknowledgements		12. Acknowledgements
	Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,		Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
	Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang		Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
	Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and		Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and
	comments.		comments.
			Thanks to the core WG for the recommendations on Hop-Limit and
			redirect signaling.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[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>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	skipping to change at page 84, line 40 ¶		skipping to change at page 82, line 40 ¶
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/info/rfc8323>.		<https://www.rfc-editor.org/info/rfc8323>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	13.2. Informative References		13.2. Informative References
			[I-D.boucadair-core-hop-limit]
			Boucadair, M., Reddy, T., and J. Shallow, "Constrained
			Application Protocol (CoAP) Hop Limit Option", draft-
			boucadair-core-hop-limit-00 (work in progress), August
			2018.
	[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-03 (work in		Management Interface", draft-ietf-core-comi-03 (work in
	progress), June 2018.		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.
	skipping to change at page 85, line 37 ¶		skipping to change at page 83, line 48 ¶
	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-16 (work		Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
	in progress), July 2018.		in progress), July 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-28 (work in progress), July		1.3", draft-ietf-tls-dtls13-28 (work in progress), July
	2018.		2018.
	[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	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>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18,		[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
	RFC 1983, DOI 10.17487/RFC1983, August 1996,		RFC 1983, DOI 10.17487/RFC1983, August 1996,
	skipping to change at page 86, line 43 ¶		skipping to change at page 85, line 5 ¶
	2007, <https://www.rfc-editor.org/info/rfc4787>.		2007, <https://www.rfc-editor.org/info/rfc4787>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<https://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common		[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
	Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,		Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
	<https://www.rfc-editor.org/info/rfc4987>.		<https://www.rfc-editor.org/info/rfc4987>.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
	January 2008, <https://www.rfc-editor.org/info/rfc5077>.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	DOI 10.17487/RFC5389, October 2008,		DOI 10.17487/RFC5389, October 2008,
	<https://www.rfc-editor.org/info/rfc5389>.		<https://www.rfc-editor.org/info/rfc5389>.
	[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>.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
End of changes. 66 change blocks.
	288 lines changed or deleted		192 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/