rfc8782xml2.original.xml   rfc8782.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc
<?rfc tocompact="yes"?> xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc tocdepth="4"?> category="std"
<?rfc tocindent="yes"?> docName="draft-ietf-dots-signal-channel-41"
<?rfc symrefs="yes"?> number="8782" ipr="trust200902"
<?rfc sortrefs="yes"?> obsoletes=""
<?rfc comments="yes"?> updates=""
<?rfc inline="yes"?> submissionType="IETF"
<?rfc compact="yes"?> consensus="true"
<?rfc subcompact="no"?> xml:lang="en"
<rfc category="std" docName="draft-ietf-dots-signal-channel-41" tocInclude="true"
ipr="trust200902"> tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 -->
<front> <front>
<title abbrev="DOTS Signal Channel Protocol">Distributed Denial-of-Service <title abbrev="DOTS Signal Channel Protocol">Distributed Denial-of-Service
Open Threat Signaling (DOTS) Signal Channel Specification</title> Open Threat Signaling (DOTS) Signal Channel Specification</title>
<seriesInfo name="RFC" value="8782"/>
<author fullname="Tirumaleswar Reddy" initials="T." role="editor" <author fullname="Tirumaleswar Reddy.K" initials="T." role="editor" surname=
surname="Reddy"> "Reddy.K">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization abbrev="McAfee">McAfee, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
<author fullname="Mohamed Boucadair" initials="M." role="editor" ucadair">
surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Rennes</city> <city>Rennes</city>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Prashanth Patil" initials="P." surname="Patil"> <author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal>
<street></street>
<street></street>
<city></city>
<country></country>
</postal>
<email>praspati@cisco.com</email> <email>praspati@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Andrew Mortensen" initials="A." surname="Mortensen"> <author fullname="Andrew Mortensen" initials="A." surname="Mortensen">
<organization>Arbor Networks, Inc.</organization> <organization>Arbor Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2727 S. State St</street> <street>2727 S. State Street</street>
<city>Ann Arbor</city>
<city>Ann Arbor, MI</city> <region>MI</region>
<region></region>
<code>48104</code> <code>48104</code>
<country>United States of America</country>
<country>United States</country>
</postal> </postal>
<email>andrew@moretension.com</email> <email>andrew@moretension.com</email>
</address> </address>
</author> </author>
<author fullname="Nik Teague" initials="N." surname="Teague"> <author fullname="Nik Teague" initials="N." surname="Teague">
<organization>Iron Mountain Data Centers</organization> <organization>Iron Mountain Data Centers</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>nteague@ironmountain.co.uk</email> <email>nteague@ironmountain.co.uk</email>
</address> </address>
</author> </author>
<date month="May" year="2020"/>
<date />
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>security</keyword> <keyword>security</keyword>
<keyword>mitigation</keyword> <keyword>mitigation</keyword>
<keyword>service delivery</keyword> <keyword>service delivery</keyword>
<keyword>connectivity</keyword> <keyword>connectivity</keyword>
<keyword>anti-DDoS</keyword> <keyword>anti-DDoS</keyword>
<keyword>automation</keyword> <keyword>automation</keyword>
<keyword>cooperation</keyword> <keyword>cooperation</keyword>
<keyword>resilience</keyword> <keyword>resilience</keyword>
<keyword>filtering</keyword> <keyword>filtering</keyword>
<keyword>security center</keyword> <keyword>security center</keyword>
<keyword>mitigator</keyword> <keyword>mitigator</keyword>
<keyword>scrubbing</keyword> <keyword>scrubbing</keyword>
<keyword>dynamic service protection</keyword> <keyword>dynamic service protection</keyword>
<keyword>dynamic mitigation</keyword> <keyword>dynamic mitigation</keyword>
<keyword>cooperative networking</keyword> <keyword>cooperative networking</keyword>
<keyword>protective networking</keyword> <keyword>protective networking</keyword>
<abstract> <abstract>
<t>This document specifies the DOTS signal channel, a protocol for <t>This document specifies the Distributed Denial-of-Service
Open Threat Signaling (DOTS) signal channel, a protocol for
signaling the need for protection against Distributed Denial-of-Service signaling the need for protection against Distributed Denial-of-Service
(DDoS) attacks to a server capable of enabling network traffic (DDoS) attacks to a server capable of enabling network traffic
mitigation on behalf of the requesting client.</t> mitigation on behalf of the requesting client.</t>
<t>A companion document defines the DOTS data channel, a separate <t>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
purposes.</t> purposes.</t>
</abstract> </abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within the document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification";</t>
<t>"| [RFCXXXX] |"</t>
<t>reference: RFC XXXX</t>
</list></t>
<t>Please update this statement with the RFC number to be assigned to
the following documents:<list style="symbols">
<t>"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification (used to be
I-D.ietf-dots-data-channel)</t>
</list></t>
<t>Please update TBD/TBD1/TBD2 statements with the assignments made by
IANA to DOTS Signal Channel Protocol.</t>
<t>Also, please update the "revision" date of the YANG modules.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>A distributed denial-of-service (DDoS) attack is a distributed <name>Introduction</name>
<t>A Distributed Denial-of-Service (DDoS) attack is a distributed
attempt to make machines or network resources unavailable to their attempt to make machines or network resources unavailable to their
intended users. In most cases, sufficient scale for an effective attack intended users. In most cases, sufficient scale for an effective attack
can be achieved by compromising enough end-hosts and using those can be achieved by compromising enough end hosts and using those
infected hosts to perpetrate and amplify the attack. The victim in this infected hosts to perpetrate and amplify the attack. The victim in this
attack can be an application server, a host, a router, a firewall, or an attack can be an application server, a host, a router, a firewall, or an
entire network.</t> entire network.</t>
<t>
<t>Network applications have finite resources like CPU cycles, the Network applications have finite resources like CPU cycles, the
number of processes or threads they can create and use, the maximum number of processes or threads they can create and use, the maximum
number of simultaneous connections they can handle, the limited number of simultaneous connections they can handle, the resources
resources of the control plane, etc. When processing network traffic, assigned to the control plane, etc. When processing network traffic,
such applications are supposed to use these resources to provide the such applications are supposed to use these resources to provide the
intended functionality in the most efficient manner. However, a DDoS intended functionality in the most efficient manner. However, a DDoS
attacker may be able to prevent an application from performing its attacker may be able to prevent an application from performing its
intended task by making the application exhaust its finite intended task by making the application exhaust its finite
resources.</t> resources.</t>
<t>A TCP DDoS SYN flood <xref target="RFC4987" format="default"/>, for exa
<t>A TCP DDoS SYN-flood <xref target="RFC4987"></xref>, for example, is mple, is
a memory-exhausting attack while an ACK-flood is a CPU-exhausting a memory-exhausting attack while an ACK flood is a CPU-exhausting
attack. Attacks on the link are carried out by sending enough traffic so attack. Attacks on the link are carried out by sending enough traffic so
that the link becomes congested, thereby likely causing packet loss for that the link becomes congested, thereby likely causing packet loss for
legitimate traffic. Stateful firewalls can also be attacked by sending legitimate traffic.
traffic that causes the firewall to maintain an excessive number of Stateful firewalls can also be attacked by sending traffic
states that may jeopardize the firewall's operation overall, besides that causes the firewall to maintain an excessive number of states
likely performance impacts. The firewall then runs out of memory, and that may jeopardize the firewall's operation overall, in addition to likely
can no longer instantiate the states required to process legitimate performance impacts.
flows. Other possible DDoS attacks are discussed in <xref The firewall then runs out of memory, and
target="RFC4732"></xref>.</t> it can no longer instantiate the states required to process legitimate
flows. Other possible DDoS attacks are discussed in <xref target="RFC4732"
format="default"/>.</t>
<t>In many cases, it may not be possible for network administrators to <t>In many cases, it may not be possible for network administrators to
determine the cause(s) of an attack. They may instead just realize that determine the cause(s) of an attack. They may instead just realize that
certain resources seem to be under attack. This document defines a certain resources seem to be under attack. This document defines a
lightweight protocol that allows a DOTS client to request mitigation lightweight protocol that allows a DOTS client to request mitigation
from one or more DOTS servers for protection against detected, from one or more DOTS servers for protection against detected,
suspected, or anticipated attacks. This protocol enables cooperation suspected, or anticipated attacks. This protocol enables cooperation
between DOTS agents to permit a highly-automated network defense that is between DOTS agents to permit a highly automated network defense that is
robust, reliable, and secure. Note that "secure" means the support of robust, reliable, and secure. Note that "secure" means the support of
the features defined in Section 2.4 of <xref the features defined in <xref target="RFC8612" section="2.4" sectionFormat
target="RFC8612"></xref>.</t> ="of" format="default"/>.</t>
<t>An example of a network diagram that illustrates a deployment of DOTS <t>An example of a network diagram that illustrates a deployment of DOTS
agents is shown in <xref target="fig1"></xref>. In this example, a DOTS agents is shown in <xref target="fig1" format="default"/>. In this example , a DOTS
server is operating on the access network. A DOTS client is located on server is operating on the access network. A DOTS client is located on
the LAN (Local Area Network), while a DOTS gateway is embedded in the the LAN (Local Area Network), while a DOTS gateway is embedded in the
CPE (Customer Premises Equipment).</t> CPE (Customer Premises Equipment).</t>
<figure anchor="fig1">
<t><figure anchor="fig1" title="Sample DOTS Deployment (1)"> <name>Sample DOTS Deployment (1)</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Network Network
Resource CPE router Access network __________ Resource CPE Router Access Network __________
+-----------+ +--------------+ +-------------+ / \ +-----------+ +--------------+ +-------------+ / \
| |___| |____| |___ | Internet | | |___| |____| |___ | Internet |
|DOTS client| | DOTS gateway | | DOTS server | | | |DOTS Client| | DOTS Gateway | | DOTS Server | | |
| | | | | | | | | | | | | | | |
+-----------+ +--------------+ +-------------+ \__________/]]></artwork> +-----------+ +--------------+ +-------------+ \__________/
</figure></t> ]]></artwork>
</figure>
<t>DOTS servers can also be reachable over the Internet, as depicted in <t>DOTS servers can also be reachable over the Internet, as depicted in
<xref target="fig_blah"></xref>.</t> <xref target="fig_blah" format="default"/>.</t>
<figure anchor="fig_blah">
<t><figure anchor="fig_blah" title="Sample DOTS Deployment (2)"> <name>Sample DOTS Deployment (2)</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Network DDoS mitigation Network DDoS Mitigation
Resource CPE router __________ service Resource CPE Router __________ Service
+-----------+ +-------------+ / \ +-------------+ +-----------+ +--------------+ / \ +-------------+
| |___| |____| |___ | | | |___| |____| |___ | |
|DOTS client| |DOTS gateway | | Internet | | DOTS server | |DOTS Client| | DOTS Gateway | | Internet | | DOTS Server |
| | | | | | | | | | | | | | | |
+-----------+ +-------------+ \__________/ +-------------+ +-----------+ +--------------+ \__________/ +-------------+
]]></artwork> ]]></artwork>
</figure>In typical deployments, the DOTS client belongs to a -----------+ <span class="insert">+--------------+</span> \__________/ +
-------------+
</figure>
<t>In typical deployments, the DOTS client belongs to a
different administrative domain than the DOTS server. For example, the different administrative domain than the DOTS server. For example, the
DOTS client is embedded in a firewall protecting services owned and DOTS client is embedded in a firewall protecting services owned and
operated by a customer, while the DOTS server is owned and operated by a operated by a customer, while the DOTS server is owned and operated by a
different administrative entity (service provider, typically) providing different administrative entity (service provider, typically) providing
DDoS mitigation services. The latter might or might not provide DDoS mitigation services. The latter might or might not provide
connectivity services to the network hosting the DOTS client.</t> connectivity services to the network hosting the DOTS client.</t>
<t>The DOTS server may (not) be co-located with the DOTS mitigator. In <t>The DOTS server may (not) be co-located with the DOTS mitigator. In
typical deployments, the DOTS server belongs to the same administrative typical deployments, the DOTS server belongs to the same administrative
domain as the mitigator. The DOTS client can communicate directly with a domain as the mitigator. The DOTS client can communicate directly with a
DOTS server or indirectly via a DOTS gateway.</t> DOTS server or indirectly via a DOTS gateway.</t>
<t>This document adheres to the DOTS architecture <xref target="I-D.ietf-d
<t>The document adheres to the DOTS architecture <xref ots-architecture" format="default"/>. The requirements for DOTS
target="I-D.ietf-dots-architecture"></xref>. The requirements for DOTS signal channel protocol are documented in <xref target="RFC8612" format="d
signal channel protocol are documented in <xref efault"/>. This document satisfies all the use cases
target="RFC8612"></xref>. This document satisfies all the use cases discussed in <xref target="I-D.ietf-dots-use-cases" format="default"/>.</t
discussed in <xref target="I-D.ietf-dots-use-cases"></xref>.</t> >
<t>This document focuses on the DOTS signal channel. This is a companion <t>This document focuses on the DOTS signal channel. This is a companion
document of the DOTS data channel specification <xref document of the DOTS data channel specification <xref target="RFC8783" for
target="I-D.ietf-dots-data-channel"></xref> that defines a configuration mat="default"/> that defines a configuration
and a bulk data exchange mechanism supporting the DOTS signal and a bulk data exchange mechanism supporting the DOTS signal
channel.</t> channel.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and /bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
bed in BCP 14
<xref target="RFC2119" format="default"/><xref target="RFC8174" format="de
fault"/> when, and
only when, they appear in all capitals, as shown here.</t> only when, they appear in all capitals, as shown here.</t>
<t>(D)TLS is used for statements that apply to both Transport Layer <t>(D)TLS is used for statements that apply to both Transport Layer
Security <xref target="RFC5246"></xref><xref target="RFC8446"></xref> Security <xref target="RFC5246" format="default"/> <xref target="RFC8446"
and Datagram Transport Layer Security <xref target="RFC6347"></xref>. format="default"/>
and Datagram Transport Layer Security <xref target="RFC6347" format="defau
lt"/>.
Specific terms are used for any statement that applies to either Specific terms are used for any statement that applies to either
protocol alone.</t> protocol alone.</t>
<t>The reader should be familiar with the terms defined in <xref target="R
<t>The reader should be familiar with the terms defined in <xref FC8612" format="default"/>.</t>
target="RFC8612"></xref>.</t> <t>The meaning of the symbols in YANG tree diagrams is defined in <xref ta
rget="RFC8340" format="default"/>.</t>
<t>The meaning of the symbols in YANG tree diagrams is defined in <xref
target="RFC8340"></xref>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Design Overview"> <name>Design Overview</name>
<t>The DOTS signal channel is built on top of the Constrained <t>The DOTS signal channel is built on top of the Constrained
Application Protocol (CoAP) <xref target="RFC7252"></xref>, a Application Protocol (CoAP) <xref target="RFC7252" format="default"/>, a
lightweight protocol originally designed for constrained devices and lightweight protocol originally designed for constrained devices and
networks. The many features of CoAP (expectation of packet loss, support networks. The many features of CoAP (expectation of packet loss, support
for asynchronous Non-confirmable messaging, congestion control, small for asynchronous Non-confirmable messaging, congestion control, small
message overhead limiting the need for fragmentation, use of minimal message overhead limiting the need for fragmentation, use of minimal
resources, and support for (D)TLS) makes it a good candidate to build resources, and support for (D)TLS) make it a good candidate upon which to
the DOTS signaling mechanism from.</t> build
the DOTS signaling mechanism.</t>
<t>DOTS clients and servers behave as CoAP endpoints. By default, a DOTS <t>DOTS clients and servers behave as CoAP endpoints. By default, a DOTS
client (or server) behaves as a CoAP client (or server). Nevertheless, a client (or server) behaves as a CoAP client (or server). Nevertheless, a
DOTS client (or server) behaves as a CoAP server (or client) for DOTS client (or server) behaves as a CoAP server (or client) for
specific operations such as DOTS heartbeat operations (<xref specific operations such as DOTS heartbeat operations (<xref target="hb" f
target="hb"></xref>).</t> ormat="default"/>).</t>
<t>The DOTS signal channel is layered on existing standards (see
<t>The DOTS signal channel is layered on existing standards (<xref <xref target="fig_dots" format="default"/>).</t>
target="fig_dots"></xref>).</t> <figure anchor="fig_dots">
<name>Abstract Layering of DOTS Signal Channel over CoAP over (D)TLS</na
<t><figure anchor="fig_dots" me>
title="Abstract Layering of DOTS Signal Channel over CoAP over (D)TLS" <artwork align="center" name="" type="" alt=""><![CDATA[
> +---------------------+
<artwork align="center"><![CDATA[+---------------------+
| DOTS Signal Channel | | DOTS Signal Channel |
+---------------------+ +---------------------+
| CoAP | | CoAP |
+----------+----------+ +----------+----------+
| TLS | DTLS | | TLS | DTLS |
+----------+----------+ +----------+----------+
| TCP | UDP | | TCP | UDP |
+----------+----------+ +----------+----------+
| IP | | IP |
+---------------------+ +---------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>In some cases, a DOTS client and server may have mutual agreement to <t>In some cases, a DOTS client and server may have a mutual agreement to
use a specific port number, such as by explicit configuration or dynamic use a specific port number, such as by explicit configuration or dynamic
discovery <xref target="I-D.ietf-dots-server-discovery"></xref>. Absent discovery <xref target="I-D.ietf-dots-server-discovery" format="default"/>
such mutual agreement, the DOTS signal channel MUST run over port number . Absent
TBD as defined in <xref target="port"></xref>, for both UDP and TCP. In such mutual agreement, the DOTS signal channel <bcp14>MUST</bcp14> run ove
order to use a distinct port number (as opposed to TBD), DOTS clients r port number
and servers SHOULD support a configurable parameter to supply the port 4646 as defined in <xref target="port" format="default"/>, for both UDP an
d TCP. In
order to use a distinct port number (as opposed to 4646), DOTS clients
and servers <bcp14>SHOULD</bcp14> support a configurable parameter to supp
ly the port
number to use.</t> number to use.</t>
<aside>
<t><list style="empty">
<t>Note: The rationale for not using the default port number 5684 <t>Note: The rationale for not using the default port number 5684
((D)TLS CoAP) is to avoid the discovery of services and resources ((D)TLS CoAP) is to avoid the discovery of services and resources
discussed in <xref target="RFC7252"></xref> and allow for discussed in <xref target="RFC7252" format="default"/> and allow for
differentiated behaviors in environments where both a DOTS gateway differentiated behaviors in environments where both a DOTS gateway
and an IoT gateway (e.g., Figure 3 of <xref and an Internet of Things (IoT) gateway (e.g., Figure 3 of <xref targe
target="RFC7452"></xref>) are co-located. <vspace t="RFC7452" format="default"/>) are co-located. </t>
blankLines="1" />Particularly, the use of a default port number is <t>Particularly, the use of a default port number is
meant to simplify DOTS deployment in scenarios where no explicit IP meant to simplify DOTS deployment in scenarios where no explicit IP
address configuration is required. For example, the use of the address configuration is required. For example, the use of the
default router as DOTS server aims to ease DOTS deployment within default router as the DOTS server aims to ease DOTS deployment within
LANs (in which, CPEs embed a DOTS gateway as illustrated in Figures LANs (in which CPEs embed a DOTS gateway as illustrated in Figures
<xref format="counter" target="fig1"></xref> and <xref <xref format="counter" target="fig1"/> and <xref format="counter" targ
format="counter" target="fig_blah"></xref>) without requiring a et="fig_blah"/>) without requiring a
sophisticated discovery method and configuration tasks within the sophisticated discovery method and configuration tasks within the
LAN. It is also possible to use anycast addresses for DOTS servers LAN. It is also possible to use anycast addresses for DOTS servers
to simplify DOTS client configuration, including service discovery. to simplify DOTS client configuration, including service discovery.
In such anycast-based scenario, a DOTS client initiating a DOTS In such an anycast-based scenario, a DOTS client initiating a DOTS
session to the DOTS server anycast address may, for example, be (1) session to the DOTS server anycast address may, for example, be (1)
redirected to the DOTS server unicast address to be used by the DOTS redirected to the DOTS server unicast address to be used by the DOTS
client following the procedure discussed in <xref client following the procedure discussed in <xref target="redirect" fo
target="redirect"></xref> or (2) relayed to a unicast DOTS rmat="default"/> or (2) relayed to a unicast DOTS
server.</t> server.</t>
</list>The signal channel uses the "coaps" URI scheme defined in
Section 6 of <xref target="RFC7252"></xref> and the "coaps+tcp" URI
scheme defined in Section 8.2 of <xref target="RFC8323"></xref> to
identify DOTS server resources accessible using CoAP over UDP secured
with DTLS and CoAP over TCP secured with TLS, respectively.</t>
</aside>
<t>The signal channel uses the "coaps" URI scheme defined in
<xref target="RFC7252" section="6" sectionFormat="of" format="default"/> a
nd the "coaps+tcp" URI
scheme defined in <xref target="RFC8323" section="8.2" sectionFormat="of"
format="default"/> to
identify DOTS server resources that are accessible using CoAP over UDP sec
ured
with DTLS and CoAP over TCP secured with TLS, respectively.</t>
<t>The DOTS signal channel can be established between two DOTS agents <t>The DOTS signal channel can be established between two DOTS agents
prior or during an attack. The DOTS signal channel is initiated by the prior to or during an attack. The DOTS signal channel is initiated by the
DOTS client. The DOTS client can then negotiate, configure, and retrieve DOTS client. The DOTS client can then negotiate, configure, and retrieve
the DOTS signal channel session behavior with its DOTS peer (<xref the DOTS signal channel session behavior with its DOTS peer (<xref target=
target="sigconfig"></xref>). Once the signal channel is established, the "sigconfig" format="default"/>). Once the signal channel is established, the
DOTS agents may periodically send heartbeats to keep the channel active DOTS agents may periodically send heartbeats to keep the channel active
(<xref target="hb"></xref>). At any time, the DOTS client may send a (<xref target="hb" format="default"/>). At any time, the DOTS client may s
mitigation request message (<xref target="m_req"></xref>) to a DOTS end a
mitigation request message (<xref target="m_req" format="default"/>) to a
DOTS
server over the active signal channel. While mitigation is active server over the active signal channel. While mitigation is active
(because of the higher likelihood of packet loss during a DDoS attack), (because of the higher likelihood of packet loss during a DDoS attack),
the DOTS server periodically sends status messages to the client, the DOTS server periodically sends status messages to the client,
including basic mitigation feedback details. Mitigation remains active including basic mitigation feedback details. Mitigation remains active
until the DOTS client explicitly terminates mitigation, or the until the DOTS client explicitly terminates mitigation or the
mitigation lifetime expires. Also, the DOTS server may rely on the mitigation lifetime expires. Also, the DOTS server may rely on the
signal channel session loss to trigger mitigation for pre-configured signal channel session loss to trigger mitigation for preconfigured
mitigation requests (if any).</t> mitigation requests (if any).</t>
<t>DOTS signaling can happen with DTLS over UDP and TLS over TCP. <t>DOTS signaling can happen with DTLS over UDP and TLS over TCP.
Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer
capabilities. A Happy Eyeballs procedure for DOTS signal channel is capabilities. A Happy Eyeballs procedure for the DOTS signal channel is
specified in <xref target="HE"></xref>.</t> specified in <xref target="HE" format="default"/>.</t>
<t>A DOTS client is entitled to access only the resources it creates. In
<t>A DOTS client is entitled to access only to resources it creates. In particular, a DOTS client cannot retrieve data related to mitigation
particular, a DOTS client can not retrieve data related to mitigation
requests created by other DOTS clients of the same DOTS client requests created by other DOTS clients of the same DOTS client
domain.</t> domain.</t>
<t>Messages exchanged between DOTS agents are serialized using Concise <t>Messages exchanged between DOTS agents are serialized using Concise
Binary Object Representation (CBOR) <xref target="RFC7049"></xref>, a Binary Object Representation (CBOR) <xref target="RFC7049" format="default "/>, a
binary encoding scheme designed for small code and message size. binary encoding scheme designed for small code and message size.
CBOR-encoded payloads are used to carry signal channel-specific payload CBOR-encoded payloads are used to carry signal channel-specific payload
messages which convey request parameters and response information such messages that convey request parameters and response information such
as errors. In order to allow reusing data models across protocols, <xref as errors. In order to allow the reusing of data models across protocols,
target="RFC7951"></xref> specifies the JavaScript Object Notation (JSON) <xref target="RFC7951" format="default"/> specifies the JavaScript Object Notati
on (JSON)
encoding of YANG-modeled data. A similar effort for CBOR is defined in encoding of YANG-modeled data. A similar effort for CBOR is defined in
<xref target="I-D.ietf-core-yang-cbor"></xref>.</t> <xref target="I-D.ietf-core-yang-cbor" format="default"/>.</t>
<t>DOTS agents determine that a CBOR data structure is a DOTS signal <t>DOTS agents determine that a CBOR data structure is a DOTS signal
channel object from the application context, such as from the port channel object from the application context, such as from the port
number assigned to the DOTS signal channel. The other method DOTS agents number assigned to the DOTS signal channel. The other method DOTS agents
use to indicate that a CBOR data structure is a DOTS signal channel use to indicate that a CBOR data structure is a DOTS signal channel
object is the use of the "application/dots+cbor" content type (<xref object is the use of the "application/dots+cbor" content type (<xref targe
target="MediaReg"></xref>).</t> t="MediaReg" format="default"/>).</t>
<t>This document specifies a YANG module for representing DOTS <t>This document specifies a YANG module for representing DOTS
mitigation scopes, DOTS signal channel session configuration data, and mitigation scopes, DOTS signal channel session configuration data, and
DOTS redirected signaling (<xref target="YANG"></xref>). All parameters DOTS redirected signaling (<xref target="YANG" format="default"/>). All pa rameters
in the payload of the DOTS signal channel are mapped to CBOR types as in the payload of the DOTS signal channel are mapped to CBOR types as
specified in <xref target="mapping">Table 4</xref>.</t> specified in <xref target="cbor-key-values" format="default"/> (<xref targ
et="mapping" format="default"/>).</t>
<t>In order to prevent fragmentation, DOTS agents must follow the <t>In order to prevent fragmentation, DOTS agents must follow the
recommendations documented in Section 4.6 of <xref recommendations documented in <xref target="RFC7252" section="4.6" section
target="RFC7252"></xref>. Refer to <xref target="mtu"></xref> for more Format="of" format="default"/>. Refer to <xref target="mtu" format="default"/> f
or more
details.</t> details.</t>
<t>DOTS agents <bcp14>MUST</bcp14> support GET, PUT, and DELETE CoAP metho
<t>DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The ds. The
payload included in CoAP responses with 2.xx Response Codes MUST be of payload included in CoAP responses with 2.xx Response Codes <bcp14>MUST</b
cp14> be of
content type "application/dots+cbor". CoAP responses with 4.xx and 5.xx content type "application/dots+cbor". CoAP responses with 4.xx and 5.xx
error Response Codes MUST include a diagnostic payload (Section 5.5.2 of error Response Codes <bcp14>MUST</bcp14> include a diagnostic payload
<xref target="RFC7252"></xref>). The Diagnostic Payload may contain (<xref target="RFC7252" section="5.5.2" sectionFormat="of" format="default"/>).
The diagnostic payload may contain
additional information to aid troubleshooting.</t> additional information to aid troubleshooting.</t>
<t>In deployments where multiple DOTS clients are enabled in a network <t>In deployments where multiple DOTS clients are enabled in a network
(owned and operated by the same entity), the DOTS server may detect (owned and operated by the same entity), the DOTS server may detect
conflicting mitigation requests from these clients. This document does conflicting mitigation requests from these clients. This document does
not aim to specify a comprehensive list of conditions under which a DOTS not aim to specify a comprehensive list of conditions under which a DOTS
server will characterize two mitigation requests from distinct DOTS server will characterize two mitigation requests from distinct DOTS
clients as conflicting, nor recommend a DOTS server behavior for clients as conflicting, nor does it recommend a DOTS server behavior for
processing conflicting mitigation requests. Those considerations are processing conflicting mitigation requests. Those considerations are
implementation- and deployment-specific. Nevertheless, the document implementation and deployment specific. Nevertheless, this document
specifies the mechanisms to notify DOTS clients when conflicts occur, specifies the mechanisms to notify DOTS clients when conflicts occur,
including the conflict cause (<xref target="m_req"></xref>).</t> including the conflict cause (<xref target="m_req" format="default"/>).</t
>
<t>In deployments where one or more translators (e.g., Traditional NAT <t>In deployments where one or more translators (e.g., Traditional NAT
<xref target="RFC3022"></xref>, CGN <xref target="RFC6888"></xref>, <xref target="RFC3022" format="default"/>, CGN <xref target="RFC6888" form
NAT64 <xref target="RFC6146"></xref>, NPTv6 <xref at="default"/>,
target="RFC6296"></xref>) are enabled between the client's network and NAT64 <xref target="RFC6146" format="default"/>, NPTv6 <xref target="RFC62
the DOTS server, DOTS signal channel messages forwarded to a DOTS server 96" format="default"/>) are enabled between the client's network and
MUST NOT include internal IP addresses/prefixes and/or port numbers; the DOTS server, any DOTS signal channel messages forwarded to a DOTS serv
er
<bcp14>MUST NOT</bcp14> include internal IP addresses/prefixes
and/or port numbers; instead,
external addresses/prefixes and/or port numbers as assigned by the external addresses/prefixes and/or port numbers as assigned by the
translator MUST be used instead. This document does not make any translator <bcp14>MUST</bcp14> be used. This document does not make any
recommendation about possible translator discovery mechanisms. The recommendations about possible translator discovery mechanisms. The
following are some (non-exhaustive) deployment examples that may be following are some (non-exhaustive) deployment examples that may be
considered: <list style="symbols"> considered: </t>
<t>Port Control Protocol (PCP) <xref target="RFC6887"></xref> or <ul spacing="normal">
Session Traversal Utilities for NAT (STUN) <xref
target="RFC5389"></xref> may be used to retrieve the external <li>Port Control Protocol (PCP) <xref target="RFC6887" format="default"/
> or
Session Traversal Utilities for NAT (STUN) <xref target="RFC8489" form
at="default"/> may be used to retrieve the external
addresses/prefixes and/or port numbers. Information retrieved by addresses/prefixes and/or port numbers. Information retrieved by
means of PCP or STUN will be used to feed the DOTS signal channel means of PCP or STUN will be used to feed the DOTS signal channel
messages that will be sent to a DOTS server.</t> messages that will be sent to a DOTS server.</li>
<li>A DOTS gateway may be co-located with the translator. The DOTS
<t>A DOTS gateway may be co-located with the translator. The DOTS gateway will need to update the DOTS messages based upon the local
gateway will need to update the DOTS messages, based upon the local translator's binding table.</li>
translator's binding table.</t> </ul>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Signal Channel: Messages &amp; Behaviors"> <name>DOTS Signal Channel: Messages &amp; Behaviors</name>
<section anchor="discover" title="DOTS Server(s) Discovery"> <section anchor="discover" numbered="true" toc="default">
<name>DOTS Server(s) Discovery</name>
<t>This document assumes that DOTS clients are provisioned with the <t>This document assumes that DOTS clients are provisioned with the
reachability information of their DOTS server(s) using any of a reachability information of their DOTS server(s) using any of a
variety of means (e.g., local configuration, or dynamic means such as variety of means (e.g., local configuration or dynamic means such as
DHCP <xref target="I-D.ietf-dots-server-discovery"></xref>). The DHCP <xref target="I-D.ietf-dots-server-discovery" format="default"/>).
The
description of such means is out of scope of this document.</t> description of such means is out of scope of this document.</t>
<t>Likewise, it is out of the scope of this document to specify the
<t>Likewise, it is out of scope of this document to specify the behavior to be followed by a DOTS client in order to send DOTS requests
behavior to be followed by a DOTS client to send DOTS requests when when
multiple DOTS servers are provisioned (e.g., contact all DOTS servers, multiple DOTS servers are provisioned (e.g., contact all DOTS servers,
select one DOTS server among the list). Such behavior is specified in select one DOTS server among the list). Such behavior is specified in
other documents (e.g., <xref other documents (e.g., <xref target="I-D.ietf-dots-multihoming" format="
target="I-D.ietf-dots-multihoming"></xref>).</t> default"/>).</t>
</section> </section>
<section anchor="uri-path" numbered="true" toc="default">
<section anchor="uri-path" title="CoAP URIs"> <name>CoAP URIs</name>
<t>The DOTS server MUST support the use of the path-prefix of <t>The DOTS server <bcp14>MUST</bcp14> support the use of the path prefi
"/.well-known/" as defined in <xref target="RFC8615"></xref> and the x of
registered name of "dots". Each DOTS operation is indicated by a "/.well-known/" as defined in <xref target="RFC8615" format="default"/>
path-suffix that indicates the intended operation. The operation path and the
(<xref target="uris"></xref>) is appended to the path-prefix to form registered name of "dots". Each DOTS operation is denoted by a
path suffix that indicates the intended operation. The operation path
(<xref target="uris" format="default"/>) is appended to the path prefix
to form
the URI used with a CoAP request to perform the desired DOTS the URI used with a CoAP request to perform the desired DOTS
operation.</t> operation.</t>
<table align="center" anchor="uris">
<texttable align="center" anchor="uris" style="all" <name>Operations and Corresponding URIs</name>
title="Operations and their Corresponding URIs"> <thead>
<ttcol>Operation</ttcol> <tr>
<th align="left">Operation</th>
<ttcol>Operation Path</ttcol> <th align="left">Operation Path</th>
<th align="left">Details</th>
<ttcol>Details</ttcol> </tr>
</thead>
<c>Mitigation</c> <tbody>
<tr>
<c>/mitigate</c> <td align="left">Mitigation</td>
<td align="left">/mitigate</td>
<c><xref target="m_req"></xref></c> <td align="left">
<xref target="m_req" format="default"/></td>
<c>Session configuration</c> </tr>
<tr>
<c>/config</c> <td align="left">Session configuration</td>
<td align="left">/config</td>
<c><xref target="sigconfig"></xref></c> <td align="left">
<xref target="sigconfig" format="default"/></td>
<c>Heartbeat</c> </tr>
<tr>
<c>/hb</c> <td align="left">Heartbeat</td>
<td align="left">/hb</td>
<c><xref target="hb"></xref></c> <td align="left">
</texttable> <xref target="hb" format="default"/></td>
</tr>
<t></t> </tbody>
</table>
</section> </section>
<section anchor="HE" numbered="true" toc="default">
<section anchor="HE" title="Happy Eyeballs for DOTS Signal Channel"> <name>Happy Eyeballs for DOTS Signal Channel</name>
<t><xref target="RFC8612"></xref> mentions that DOTS agents will have <t><xref target="RFC8612" format="default"/> mentions that DOTS agents w
ill have
to support both connectionless and connection-oriented protocols. As to support both connectionless and connection-oriented protocols. As
such, the DOTS signal channel is designed to operate with DTLS over such, the DOTS signal channel is designed to operate with DTLS over
UDP and TLS over TCP. Further, a DOTS client may acquire a list of UDP and TLS over TCP. Further, a DOTS client may acquire a list of
IPv4 and IPv6 addresses (<xref target="discover"></xref>), each of IPv4 and IPv6 addresses (<xref target="discover" format="default"/>), ea ch of
which can be used to contact the DOTS server using UDP and TCP. If no which can be used to contact the DOTS server using UDP and TCP. If no
list of IPv4 and IPv6 addresses to contact the DOTS server is list of IPv4 and IPv6 addresses to contact the DOTS server is
configured (or discovered), the DOTS client adds the IPv4/IPv6 configured (or discovered), the DOTS client adds the IPv4/IPv6
addresses of its default router to the candidate list to contact the addresses of its default router to the candidate list to contact the
DOTS server.</t> DOTS server.</t>
<t>The following specifies the procedure to follow to select the <t>The following specifies the procedure to follow to select the
address family and the transport protocol for sending DOTS signal address family and the transport protocol for sending DOTS signal
channel messages.</t> channel messages.</t>
<t>Such a procedure is needed to avoid experiencing long connection
<t>Such procedure is needed to avoid experiencing long connection delays. For example, if an IPv4 path to a DOTS server is
delays. For example, if an IPv4 path to reach a DOTS server is functional, but the DOTS server's IPv6 path is nonfunctional, a
functional, but the DOTS server's IPv6 path is non-functional, a
dual-stack DOTS client may experience a significant connection delay dual-stack DOTS client may experience a significant connection delay
compared to an IPv4-only DOTS client, in the same network conditions. compared to an IPv4-only DOTS client in the same network conditions.
The other problem is that if a middlebox between the DOTS client and The other problem is that if a middlebox between the DOTS client and
DOTS server is configured to block UDP traffic, the DOTS client will DOTS server is configured to block UDP traffic, the DOTS client will
fail to establish a DTLS association with the DOTS server and, as a fail to establish a DTLS association with the DOTS server;
consequence, will have to fall back to TLS over TCP, thereby incurring consequently, it will have to fall back to TLS over TCP, thereby incurrin
g
significant connection delays.</t> significant connection delays.</t>
<t>To overcome these connection setup problems, the DOTS client <t>To overcome these connection setup problems, the DOTS client
attempts to connect to its DOTS server(s) using both IPv6 and IPv4, attempts to connect to its DOTS server(s) using both IPv6 and IPv4,
and tries both DTLS over UDP and TLS over TCP following a DOTS Happy and it tries both DTLS over UDP and TLS over TCP following a DOTS Happy
Eyeballs approach. To some extent, this approach is similar to the Eyeballs approach. To some extent, this approach is similar to the
Happy Eyeballs mechanism defined in <xref target="RFC8305"></xref>. Happy Eyeballs mechanism defined in <xref target="RFC8305" format="defau lt"/>.
The connection attempts are performed by the DOTS client when it The connection attempts are performed by the DOTS client when it
initializes, or in general when it has to select an address family and initializes or, in general, when it has to select an address family and
transport to contact its DOTS server. The results of the Happy transport to contact its DOTS server. The results of the Happy
Eyeballs procedure are used by the DOTS client for sending its Eyeballs procedure are used by the DOTS client for sending its
subsequent messages to the DOTS server. The difference in behavior subsequent messages to the DOTS server. The differences in behavior
with respect to the Happy Eyeballs mechanism <xref with respect to the Happy Eyeballs mechanism <xref target="RFC8305" form
target="RFC8305"></xref> are listed below:</t> at="default"/> are listed below:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The order of preference of the DOTS signal channel address
<t>The order of preference of the DOTS signal channel address family and transport protocol (most preferred first) is the followin
family and transport protocol (most preferred first) is: UDP over g: UDP over
IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4.
This order adheres to the address preference order specified in This order adheres to the address preference order specified in
<xref target="RFC6724"></xref> and the DOTS signal channel <xref target="RFC6724" format="default"/> and the DOTS signal channe
preference which privileges the use of UDP over TCP (to avoid l
TCP's head of line blocking).</t> preference that promotes the use of UDP over TCP (to avoid
TCP's head of line blocking).</li>
<t>The DOTS client after successfully establishing a connection <li>After successfully establishing a connection, the DOTS client
MUST cache information regarding the outcome of each connection <bcp14>MUST</bcp14> cache information regarding the outcome of each
attempt for a specific time period, and it uses that information connection
attempt for a specific time period; it uses that information
to avoid thrashing the network with subsequent attempts. The to avoid thrashing the network with subsequent attempts. The
cached information is flushed when its age exceeds a specific time cached information is flushed when its age exceeds a specific time
period on the order of few minutes (e.g., 10 min). Typically, if period on the order of few minutes (e.g., 10 min). Typically, if
the DOTS client has to re-establish the connection with the same the DOTS client has to reestablish the connection with the same
DOTS server within few seconds after the Happy Eyeballs mechanism DOTS server within a few seconds after the Happy Eyeballs mechanism
is completed, caching avoids trashing the network especially in is completed, caching avoids thrashing the network especially in
the presence of DDoS attack traffic.</t> the presence of DDoS attack traffic.</li>
<li>If a DOTS signal channel session is established with TLS (but
<t>If DOTS signal channel session is established with TLS (but
DTLS failed), the DOTS client periodically repeats the mechanism DTLS failed), the DOTS client periodically repeats the mechanism
to discover whether DOTS signal channel messages with DTLS over to discover whether DOTS signal channel messages with DTLS over
UDP becomes available from the DOTS server, so the DOTS client can UDP become available from the DOTS server; this is so the DOTS clien t can
migrate the DOTS signal channel from TCP to UDP. Such probing migrate the DOTS signal channel from TCP to UDP. Such probing
SHOULD NOT be done more frequently than every 24 hours and MUST <bcp14>SHOULD NOT</bcp14> be done more frequently than every 24 hour
NOT be done more frequently than every 5 minutes.</t> s and <bcp14>MUST
</list></t> NOT</bcp14> be done more frequently than every 5 minutes.</li>
</ul>
<t><!--When connection attempts are made when no mitigation request is <t>
active, the DOTS client SHOULD use a "Connection Attempt Delay" When connection attempts are made during an attack, the DOTS client <bcp
[RFC8305] set to 5 seconds. 14>SHOULD</bcp14>
use a "Connection Attempt Delay" <xref target="RFC8305"></xref> set to use a "Connection Attempt Delay" <xref target="RFC8305" format="default"
/> set to
100 ms.</t> 100 ms.</t>
<t>In <xref target="fig_happy_eyeballs" format="default"/>, the DOTS
<t>In reference to <xref target="fig_happy_eyeballs"></xref>, the DOTS
client proceeds with the connection attempts following the rules in client proceeds with the connection attempts following the rules in
<xref target="RFC8305"></xref>. In this example, it is assumed that <xref target="RFC8305" format="default"/>. In this example, it is assume
the IPv6 path is broken and UDP traffic is dropped by a middlebox but d that
has little impact to the DOTS client because there is no long delay the IPv6 path is broken and UDP traffic is dropped by a middlebox, but t
his
has little impact on the DOTS client because there is not a long delay
before using IPv4 and TCP.</t> before using IPv4 and TCP.</t>
<figure anchor="fig_happy_eyeballs">
<t><figure anchor="fig_happy_eyeballs" <name>DOTS Happy Eyeballs (Sample Flow)</name>
title="DOTS Happy Eyeballs (Sample Flow)"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +-----------+ +-----------+ +-----------+
+-----------+ |DOTS Client| |DOTS Server|
|DOTS client| |DOTS server| +-----------+ +-----------+
+-----------+ +-----------+ | |
| | T0 |--DTLS ClientHello, IPv6 ---->X |
T0 |--DTLS ClientHello, IPv6 ---->X | T1 |--DTLS ClientHello, IPv4 ---->X |
T1 |--DTLS ClientHello, IPv4 ---->X | T2 |--TCP SYN, IPv6-------------->X |
T2 |--TCP SYN, IPv6-------------->X | T3 |--TCP SYN, IPv4------------------------------------->|
T3 |--TCP SYN, IPv4--------------------------------------->| |<-TCP SYNACK-----------------------------------------|
|<-TCP SYNACK-------------------------------------------| |--TCP ACK------------------------------------------->|
|--TCP ACK--------------------------------------------->| |<------------Establish TLS Session------------------>|
|<------------Establish TLS Session-------------------->| |----------------DOTS signal------------------------->|
|----------------DOTS signal--------------------------->| | |
| |
Note: Note:
* Retransmission messages are not shown. * Retransmission messages are not shown.
* T1-T0=T2-T1=T3-T2= Connection Attempt Delay.]]></artwork> * T1-T0=T2-T1=T3-T2= Connection Attempt Delay.
</figure></t> ]]></artwork>
</figure>
<t>A single DOTS signal channel between DOTS agents can be used to <t>A single DOTS signal channel between DOTS agents can be used to
exchange multiple DOTS signal messages. To reduce DOTS client and DOTS exchange multiple DOTS signal messages. To reduce DOTS client and DOTS
server workload, DOTS clients SHOULD re-use the (D)TLS session.</t> server workload, DOTS clients <bcp14>SHOULD</bcp14> reuse the (D)TLS ses sion.</t>
</section> </section>
<section anchor="m_req" numbered="true" toc="default">
<section anchor="m_req" title="DOTS Mitigation Methods"> <name>DOTS Mitigation Methods</name>
<t>The following methods are used by a DOTS client to request, <t>The following methods are used by a DOTS client to request,
withdraw, or retrieve the status of mitigation requests:<list withdraw, or retrieve the status of mitigation requests:</t>
hangIndent="8" style="hanging"> <dl newline="false" spacing="normal" indent="10">
<t hangText="PUT:">DOTS clients use the PUT method to request <dt>PUT:</dt>
mitigation from a DOTS server (<xref target="post"></xref>). <dd>DOTS clients use the PUT method to request
mitigation from a DOTS server (<xref target="post" format="default"/
>).
During active mitigation, DOTS clients may use PUT requests to During active mitigation, DOTS clients may use PUT requests to
carry mitigation efficacy updates to the DOTS server (<xref carry mitigation efficacy updates to the DOTS server (<xref target="
target="put"></xref>).</t> put" format="default"/>).</dd>
<dt>GET:</dt>
<t hangText="GET:">DOTS clients may use the GET method to <dd>DOTS clients may use the GET method to
subscribe to DOTS server status messages, or to retrieve the list subscribe to DOTS server status messages or to retrieve the list
of its mitigations maintained by a DOTS server (<xref of its mitigations maintained by a DOTS server (<xref target="get" f
target="get"></xref>).</t> ormat="default"/>).</dd>
<dt>DELETE:</dt>
<t hangText="DELETE:">DOTS clients use the DELETE method to <dd>DOTS clients use the DELETE method to
withdraw a request for mitigation from a DOTS server (<xref withdraw a request for mitigation from a DOTS server (<xref target="
target="del"></xref>).</t> del" format="default"/>).</dd>
</list></t> </dl>
<t>Mitigation request and response messages are marked as <t>Mitigation request and response messages are marked as
Non-confirmable messages (Section 2.2 of <xref Non-confirmable messages (<xref target="RFC7252" section="2.2" sectionFo
target="RFC7252"></xref>).</t> rmat="of" format="default"/>).</t>
<t>DOTS agents <bcp14>MUST NOT</bcp14> send more than one UDP datagram p
<t>DOTS agents MUST NOT send more than one UDP datagram per round-trip er round-trip
time (RTT) to the peer DOTS agent on average following the data time (RTT) to the peer DOTS agent on average following the data
transmission guidelines discussed in Section 3.1.3 of <xref transmission guidelines discussed in <xref target="RFC8085" section="3.1
target="RFC8085"></xref>.</t> .3" sectionFormat="of" format="default"/>.</t>
<t>Requests marked by the DOTS client as Non-confirmable messages are <t>Requests marked by the DOTS client as Non-confirmable messages are
sent at regular intervals until a response is received from the DOTS sent at regular intervals until a response is received from the DOTS
server. If the DOTS client cannot maintain an RTT estimate, it MUST server. If the DOTS client cannot maintain an RTT estimate, it <bcp14>MU
NOT send more than one Non-confirmable request every 3 seconds, and ST
SHOULD use an even less aggressive rate whenever possible (case 2 in NOT</bcp14> send more than one Non-confirmable request every 3 seconds,
Section 3.1.3 of <xref target="RFC8085"></xref>). Mitigation requests and
MUST NOT be delayed because of checks on probing rate (Section 4.7 of <bcp14>SHOULD</bcp14> use an even less aggressive rate whenever possible
<xref target="RFC7252"></xref>).</t> (case 2 in
<xref target="RFC8085" section="3.1.3" sectionFormat="of" format="defaul
<t>JSON encoding of YANG modelled data <xref target="RFC7951"></xref> t"/>). Mitigation requests
<bcp14>MUST NOT</bcp14> be delayed because of checks on probing rate
(<xref target="RFC7252" section="4.7" sectionFormat="of" format="default"/>).</t
>
<t>JSON encoding of YANG modeled data <xref target="RFC7951" format="de
fault"/>
is used to illustrate the various methods defined in the following is used to illustrate the various methods defined in the following
sub-sections. Also, the examples use the Labels defined in Sections subsections. Also, the examples use the Labels defined in Sections
<xref format="counter" target="sc"></xref>, <xref format="counter" <xref format="counter" target="sc"/>, <xref format="counter" target="cs"
target="cs"></xref>, <xref format="counter" target="cc"></xref>, and />, <xref format="counter" target="cc"/>, and
<xref format="counter" target="as"></xref>.</t> <xref format="counter" target="as"/>.</t>
<section anchor="post" numbered="true" toc="default">
<section anchor="post" title="Request Mitigation"> <name>Request Mitigation</name>
<t>When a DOTS client requires mitigation for some reason, the DOTS <t>When a DOTS client requires mitigation for some reason, the DOTS
client uses the CoAP PUT method to send a mitigation request to its client uses the CoAP PUT method to send a mitigation request to its
DOTS server(s) (Figures <xref format="counter" DOTS server(s) (Figures <xref format="counter" target="Figure1"/> and
target="Figure1"></xref> and <xref format="counter" <xref format="counter" target="Figure1c"/>).</t>
target="Figure1c"></xref>).</t>
<t>If a DOTS client is entitled to solicit the DOTS service, the <t>If a DOTS client is entitled to solicit the DOTS service, the
DOTS server enables mitigation on behalf of the DOTS client by DOTS server enables mitigation on behalf of the DOTS client by
communicating the DOTS client's request to a mitigator (which may be communicating the DOTS client's request to a mitigator (which may be
co-located with the DOTS server) and relaying the feedback of the co-located with the DOTS server) and relaying the feedback of the
thus-selected mitigator to the requesting DOTS client.</t> thus-selected mitigator to the requesting DOTS client.</t>
<figure anchor="Figure1">
<t><figure anchor="Figure1" <name>PUT to Convey DOTS Mitigation Requests</name>
title="PUT to Convey DOTS Mitigation Requests"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
... ...
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The order of the Uri-Path options is important as it defines the <t>The order of the Uri-Path options is important as it defines the
CoAP resource. In particular, 'mid' MUST follow 'cuid'.</t> CoAP resource. In particular, 'mid' <bcp14>MUST</bcp14> follow 'cuid'.
</t>
<t>The additional Uri-Path parameters to those defined in <xref <t>The additional Uri-Path parameters to those defined in <xref target
target="uri-path"></xref> are as follows:</t> ="uri-path" format="default"/> are as follows:</t>
<dl newline="false" spacing="normal" indent="6">
<t><list hangIndent="6" style="hanging"> <dt>cuid:</dt>
<t hangText="cuid:">Stands for Client Unique Identifier. A <dd>
<t>Stands for Client Unique Identifier. A
globally unique identifier that is meant to prevent collisions globally unique identifier that is meant to prevent collisions
among DOTS clients, especially those from the same domain. It among DOTS clients, especially those from the same domain. It
MUST be generated by DOTS clients.<vspace blankLines="1" />For <bcp14>MUST</bcp14> be generated by DOTS clients.</t>
the reasons discussed in <xref target="motiv"></xref>, <t>For
implementations SHOULD set 'cuid' using the following procedure: the reasons discussed in <xref target="motiv" format="default"/>,
first, the Distinguished Encoding Rules (DER)-encoded Abstract implementations <bcp14>SHOULD</bcp14> set 'cuid' using the followi
Syntax Notation One (ASN.1) representation of the Subject Public ng procedure:
Key Info (SPKI) of the DOTS client X.509 certificate <xref
target="RFC5280"></xref>, the DOTS client raw public key <xref first, the DOTS client inputs one of the following into the
target="RFC7250"></xref>, the "Pre-Shared Key (PSK) identity" SHA-256 <xref target="RFC6234" format="default"/> cryptographic hash: the DER
used by the DOTS client in the TLS 1.2 ClientKeyExchange -encoded ASN.1
message, or the "identity" used by the DOTS client in the representation of the Subject Public Key Info (SPKI) of its X.509
"pre_shared_key" TLS 1.3 extension is input to the SHA-256 <xref certificate <xref target="RFC5280" format="default"/>, its raw public key <xr
target="RFC6234"></xref> cryptographic hash. Then, the output of ef target="RFC7250" format="default"/>, the
"Pre-Shared Key (PSK) identity" it uses in the TLS 1.2
ClientKeyExchange message, or the "identity" it uses in the
"pre_shared_key" TLS 1.3 extension.
Then, the output of
the cryptographic hash algorithm is truncated to 16 bytes; the cryptographic hash algorithm is truncated to 16 bytes;
truncation is done by stripping off the final 16 bytes. The truncation is done by stripping off the final 16 bytes. The
truncated output is base64url encoded (Section 5 of <xref truncated output is base64url encoded (<xref target="RFC4648" sect
target="RFC4648"></xref>) with the trailing "=" removed from the ion="5" sectionFormat="of" format="default"/>)
encoding, and the resulting value used as the 'cuid'. <vspace with the trailing "=" removed from the
blankLines="1" />The 'cuid' is intended to be stable when encoding, and the resulting value used as the 'cuid'. </t>
<t>The 'cuid' is intended to be stable when
communicating with a given DOTS server, i.e., the 'cuid' used by communicating with a given DOTS server, i.e., the 'cuid' used by
a DOTS client SHOULD NOT change over time. Distinct 'cuid' a DOTS client <bcp14>SHOULD NOT</bcp14> change over time. Distinct
values MAY be used by a single DOTS client per DOTS server. 'cuid'
<vspace blankLines="1" />If a DOTS client has to change its values <bcp14>MAY</bcp14> be used by a single DOTS client per DOTS
'cuid' for some reason, it MUST NOT do so when mitigations are server.
still active for the old 'cuid'. The 'cuid' SHOULD be 22 </t>
<t>If a DOTS client has to change its
'cuid' for some reason, it <bcp14>MUST NOT</bcp14> do so when miti
gations are
still active for the old 'cuid'. The 'cuid' <bcp14>SHOULD</bcp14>
be 22
characters to avoid DOTS signal message fragmentation over UDP. characters to avoid DOTS signal message fragmentation over UDP.
Furthermore, if that DOTS client created aliases and filtering Furthermore, if that DOTS client created aliases and filtering
entries at the DOTS server by means of the DOTS data channel, it entries at the DOTS server by means of the DOTS data channel, it
MUST delete all the entries bound to the old 'cuid' and <bcp14>MUST</bcp14> delete all the entries bound to the old 'cuid'
re-install them using the new 'cuid'.<vspace and
blankLines="1" />DOTS servers MUST return 4.09 (Conflict) error reinstall them using the new 'cuid'.</t>
code to a DOTS peer to notify that the 'cuid' is already in-use <t>DOTS servers <bcp14>MUST</bcp14> return 4.09 (Conflict) error
code to a DOTS peer to notify that the 'cuid' is already in use
by another DOTS client. Upon receipt of that error code, a new by another DOTS client. Upon receipt of that error code, a new
'cuid' MUST be generated by the DOTS peer (e.g., using <xref 'cuid' <bcp14>MUST</bcp14> be generated by the DOTS peer (e.g., us
target="RFC4122"></xref>). <vspace ing <xref target="RFC4122" format="default"/>). </t>
blankLines="1" />Client-domain DOTS gateways MUST handle 'cuid' <t>Client-domain DOTS gateways <bcp14>MUST</bcp14> handle 'cuid'
collision directly and it is RECOMMENDED that 'cuid' collision collision directly and it is <bcp14>RECOMMENDED</bcp14> that 'cuid
is handled directly by server-domain DOTS gateways.<vspace ' collision
blankLines="1" />DOTS gateways MAY rewrite the 'cuid' used by is handled directly by server-domain DOTS gateways.</t>
<t>DOTS gateways <bcp14>MAY</bcp14> rewrite the 'cuid' used by
peer DOTS clients. Triggers for such rewriting are out of scope. peer DOTS clients. Triggers for such rewriting are out of scope.
<vspace blankLines="1" />This is a mandatory Uri-Path </t>
<t>This is a mandatory Uri-Path
parameter.</t> parameter.</t>
</dd>
<t hangText="mid:">Identifier for the mitigation request <dt>mid:</dt>
represented with an integer. This identifier MUST be unique for <dd>
<t>Identifier for the mitigation request
represented with an integer. This identifier <bcp14>MUST</bcp14> b
e unique for
each mitigation request bound to the DOTS client, i.e., the each mitigation request bound to the DOTS client, i.e., the
'mid' parameter value in the mitigation request needs to be 'mid' parameter value in the mitigation request needs to be
unique (per 'cuid' and DOTS server) relative to the 'mid' unique (per 'cuid' and DOTS server) relative to the 'mid'
parameter values of active mitigation requests conveyed from the parameter values of active mitigation requests conveyed from the
DOTS client to the DOTS server.<vspace blankLines="1" />In order DOTS client to the DOTS server.</t>
<t>In order
to handle out-of-order delivery of mitigation requests, 'mid' to handle out-of-order delivery of mitigation requests, 'mid'
values MUST increase monotonically. <vspace blankLines="1" />If values <bcp14>MUST</bcp14> increase monotonically. </t>
the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., <t>If
3221225471) and no attack is detected, the DOTS client MUST the 'mid' value has reached 3/4 of (2<sup>32</sup> - 1) (i.e.,
3221225471) and no attack is detected, the DOTS client <bcp14>MUST
</bcp14>
reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client
maintains mitigation requests with pre-configured scopes, it maintains mitigation requests with preconfigured scopes, it
MUST re-create them with the 'mid' restarting at 0. <vspace <bcp14>MUST</bcp14> recreate them with the 'mid' restarting at 0.
blankLines="1" />This identifier MUST be generated by the DOTS </t>
client.<vspace blankLines="1" />This is a mandatory Uri-Path <t>This identifier <bcp14>MUST</bcp14> be generated by the DOTS
client.</t>
<t>This is a mandatory Uri-Path
parameter.</t> parameter.</t>
</list></t> </dd>
</dl>
<t>'cuid' and 'mid' MUST NOT appear in the PUT request message body <t>'cuid' and 'mid' <bcp14>MUST NOT</bcp14> appear in the PUT request
(<xref target="Figure1c"></xref>). The schema in <xref message body
target="Figure1c"></xref> uses the types defined in <xref (<xref target="Figure1c" format="default"/>). The schema in <xref targ
target="mapping"></xref>. Note that this figure (and other similar et="Figure1c" format="default"/>
uses the types defined in <xref target="mapping" format="default"/>. N
ote that this figure (and other similar
figures depicting a schema) are non-normative sketches of the figures depicting a schema) are non-normative sketches of the
structure of the message.</t> structure of the message.</t>
<figure anchor="Figure1c">
<t><figure anchor="Figure1c" <name>PUT to Convey DOTS Mitigation Requests (Message Body Schema)</
title="PUT to Convey DOTS Mitigation Requests (Message Body Schema name>
)"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ { {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": number, "lower-port": number,
"upper-port": number "upper-port": number
skipping to change at line 831 skipping to change at line 695
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": number, "lifetime": number,
"trigger-mitigation": true|false "trigger-mitigation": true|false
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The parameters in the CBOR body (<xref target="Figure1c" format="de
<t>The parameters in the CBOR body (<xref target="Figure1c"></xref>) fault"/>)
of the PUT request are described below:</t> of the PUT request are described below:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>target-prefix:</dt>
<t hangText="target-prefix:">A list of prefixes identifying <dd>
<t>A list of prefixes identifying
resources under attack. Prefixes are represented using Classless resources under attack. Prefixes are represented using Classless
Inter-Domain Routing (CIDR) notation <xref Inter-Domain Routing (CIDR) notation <xref target="RFC4632" format
target="RFC4632"></xref>. <vspace blankLines="0" />As a ="default"/>. </t>
<t>As a
reminder, the prefix length must be less than or equal to 32 (or reminder, the prefix length must be less than or equal to 32 (or
128) for IPv4 (or IPv6).<vspace blankLines="1" />The prefix list 128) for IPv4 (or IPv6).</t>
MUST NOT include broadcast, loopback, or multicast addresses. <t>The prefix list
These addresses are considered as invalid values. In addition, <bcp14>MUST NOT</bcp14> include broadcast, loopback, or multicast
the DOTS server MUST validate that target prefixes are within addresses.
These addresses are considered to be invalid values. In addition,
the DOTS server <bcp14>MUST</bcp14> validate that target prefixes
are within
the scope of the DOTS client domain. Other validation checks may the scope of the DOTS client domain. Other validation checks may
be supported by DOTS servers.<vspace blankLines="1" />This is an be supported by DOTS servers.</t>
<t>This is an
optional attribute.</t> optional attribute.</t>
</dd>
<t hangText="target-port-range:">A list of port numbers bound to <dt>target-port-range:</dt>
resources under attack. <vspace blankLines="1" />A port range is <dd>
defined by two bounds, a lower port number (lower-port) and an <t>A list of port numbers bound to
upper port number (upper-port). When only 'lower-port' is resources under attack. </t>
present, it represents a single port number. <vspace <t>A port range is
blankLines="1" />For TCP, UDP, Stream Control Transmission defined by two bounds, a lower port number ('lower-port') and an
Protocol (SCTP) <xref target="RFC4960"></xref>, or Datagram upper port number ('upper-port'). When only 'lower-port' is
Congestion Control Protocol (DCCP) <xref present, it represents a single port number. </t>
target="RFC4340"></xref>, a range of ports can be, for example, <t>For TCP, UDP, Stream Control Transmission
0-1023, 1024-65535, or 1024-49151. <vspace blankLines="1" />This Protocol (SCTP) <xref target="RFC4960" format="default"/>, or Data
gram
Congestion Control Protocol (DCCP) <xref target="RFC4340" format="
default"/>, a range of ports can be, for example,
0-1023, 1024-65535, or 1024-49151. </t>
<t>This
is an optional attribute.</t> is an optional attribute.</t>
</dd>
<t hangText="target-protocol:">A list of protocols involved in <dt>target-protocol:</dt>
<dd>
<t>A list of protocols involved in
an attack. Values are taken from the IANA protocol registry an attack. Values are taken from the IANA protocol registry
<xref target="proto_numbers"></xref>. <vspace <xref target="IANA-Proto" format="default"/>. </t>
blankLines="1" />If 'target-protocol' is not specified, then the <t>If 'target-protocol' is not specified, then the
request applies to any protocol. <vspace blankLines="1" />This request applies to any protocol. </t>
<t>This
is an optional attribute.</t> is an optional attribute.</t>
</dd>
<t hangText="target-fqdn: ">A list of Fully Qualified Domain <dt>target-fqdn: </dt>
Names (FQDNs) identifying resources under attack <xref <dd>
target="RFC8499"></xref>.<vspace blankLines="1" />How a name is <t>A list of Fully Qualified Domain
Names (FQDNs) identifying resources under attack <xref target="RFC
8499" format="default"/>.</t>
<t>How a name is
passed to an underlying name resolution library is passed to an underlying name resolution library is
implementation- and deployment-specific. Nevertheless, once the implementation and deployment specific. Nevertheless, once the
name is resolved into one or multiple IP addresses, DOTS servers name is resolved into one or multiple IP addresses, DOTS servers
MUST apply the same validation checks as those for <bcp14>MUST</bcp14> apply the same validation checks as those for
'target-prefix'.<vspace blankLines="1" />The use of FQDNs may be 'target-prefix'.</t>
suboptimal because:<list style="symbols"> <t>The use of FQDNs may be
<t>It induces both an extra load and increased delays on the suboptimal because:</t>
<ul spacing="normal">
<li>It induces both an extra load and increased delays on the
DOTS server to handle and manage DNS resolution DOTS server to handle and manage DNS resolution
requests.</t> requests.</li>
<li>It does not guarantee that the DOTS server will resolve a
<t>It does not guarantee that the DOTS server will resolve a name to the same IP addresses that the DOTS client does.</li>
name to the same IP addresses that the DOTS client does.</t> </ul>
</list><vspace blankLines="1" />This is an optional <t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="target-uri: ">A list of Uniform Resource <dt>target-uri: </dt>
Identifiers (URIs) <xref target="RFC3986"></xref> identifying <dd>
resources under attack. <vspace blankLines="1" />The same <t>A list of URIs <xref target="RFC3986" format="default"/> identi
validation checks used for 'target-fqdn' MUST be followed by fying
DOTS servers to validate a target URI. <vspace resources under attack. </t>
blankLines="1" />This is an optional attribute.</t> <t>The same
validation checks used for 'target-fqdn' <bcp14>MUST</bcp14> be fo
<t hangText="alias-name:">A list of aliases of resources for llowed by
DOTS servers to validate a target URI. </t>
<t>This is an optional attribute.</t>
</dd>
<dt>alias-name:</dt>
<dd>
<t>A list of aliases of resources for
which the mitigation is requested. Aliases can be created using which the mitigation is requested. Aliases can be created using
the DOTS data channel (Section 6.1 of <xref the DOTS data channel (<xref target="RFC8783" section="6.1" sectio
target="I-D.ietf-dots-data-channel"></xref>), direct nFormat="of" format="default"/>), direct
configuration, or other means. <vspace blankLines="1" />An alias configuration, or other means. </t>
<t>An alias
is used in subsequent signal channel exchanges to refer more is used in subsequent signal channel exchanges to refer more
efficiently to the resources under attack.<vspace efficiently to the resources under attack.</t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd>
<t hangText="lifetime: ">Lifetime of the mitigation request in <dt>lifetime: </dt>
seconds. The RECOMMENDED lifetime of a mitigation request is <dd>
3600 seconds -- this value was chosen to be long enough so that <t>Lifetime of the mitigation request in
seconds. The <bcp14>RECOMMENDED</bcp14> lifetime of a mitigation r
equest is
3600 seconds: this value was chosen to be long enough so that
refreshing is not typically a burden on the DOTS client, while refreshing is not typically a burden on the DOTS client, while
still making the request expire in a timely manner when the still making the request expire in a timely manner when the
client has unexpectedly quit. DOTS clients MUST include this client has unexpectedly quit. DOTS clients <bcp14>MUST</bcp14> inc lude this
parameter in their mitigation requests. Upon the expiry of this parameter in their mitigation requests. Upon the expiry of this
lifetime, and if the request is not refreshed, the mitigation lifetime, and if the request is not refreshed, the mitigation
request is removed. The request can be refreshed by sending the request is removed. The request can be refreshed by sending the
same request again. <vspace blankLines="1" />A lifetime of '0' same request again. </t>
in a mitigation request is an invalid value. <vspace <t>A lifetime of '0'
blankLines="1" />A lifetime of negative one (-1) indicates in a mitigation request is an invalid value. </t>
<t>A lifetime of negative one (-1) indicates
indefinite lifetime for the mitigation request. The DOTS server indefinite lifetime for the mitigation request. The DOTS server
MAY refuse indefinite lifetime, for policy reasons; the granted <bcp14>MAY</bcp14> refuse an indefinite lifetime, for policy reaso
lifetime value is returned in the response. DOTS clients MUST be ns; the granted
lifetime value is returned in the response. DOTS clients <bcp14>MU
ST</bcp14> be
prepared to not be granted mitigations with indefinite prepared to not be granted mitigations with indefinite
lifetimes.<vspace blankLines="1" />The DOTS server MUST always lifetimes.</t>
<t>The DOTS server <bcp14>MUST</bcp14> always
indicate the actual lifetime in the response and the remaining indicate the actual lifetime in the response and the remaining
lifetime in status messages sent to the DOTS client. <vspace lifetime in status messages sent to the DOTS client. </t>
blankLines="1" />This is a mandatory attribute.</t> <t>This is a mandatory attribute.</t>
</dd>
<t hangText="trigger-mitigation: ">If the parameter value is set <dt>trigger-mitigation: </dt>
<dd>
<t>If the parameter value is set
to 'false', DDoS mitigation will not be triggered for the to 'false', DDoS mitigation will not be triggered for the
mitigation request unless the DOTS signal channel session is mitigation request unless the DOTS signal channel session is
lost. <vspace blankLines="1" />If the DOTS client ceases to lost. </t>
<t>If the DOTS client ceases to
respond to heartbeat messages, the DOTS server can detect that respond to heartbeat messages, the DOTS server can detect that
the DOTS signal channel session is lost. More details are the DOTS signal channel session is lost. More details are
discussed in <xref target="hb"></xref>.<vspace discussed in <xref target="hb" format="default"/>.</t>
blankLines="1" />The default value of the parameter is 'true' <t>The default value of the parameter is 'true'
(that is, the mitigation starts immediately). If (that is, the mitigation starts immediately). If
'trigger-mitigation' is not present in a request, this is 'trigger-mitigation' is not present in a request, this is
equivalent to receiving a request with 'trigger-mitigation' set equivalent to receiving a request with 'trigger-mitigation' set
to 'true'. <vspace blankLines="1" />This is an optional to 'true'. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</list></t> </dd>
</dl>
<t>In deployments where server-domain DOTS gateways are enabled, <t>In deployments where server-domain DOTS gateways are enabled,
identity information about the origin source client domain ('cdid') identity information about the origin source client domain ('cdid')
SHOULD be propagated to the DOTS server. That information is meant <bcp14>SHOULD</bcp14> be propagated to the DOTS server. That informati
to assist the DOTS server to enforce some policies such as grouping on is meant
to assist the DOTS server in enforcing some policies such as grouping
DOTS clients that belong to the same DOTS domain, limiting the DOTS clients that belong to the same DOTS domain, limiting the
number of DOTS requests, and identifying the mitigation scope. These number of DOTS requests, and identifying the mitigation scope. These
policies can be enforced per-client, per-client domain, or both. policies can be enforced per client, per client domain, or both.
Also, the identity information may be used for auditing and Also, the identity information may be used for auditing and
debugging purposes.</t> debugging purposes.</t>
<t><xref target="Figure1a" format="default"/> shows an example of a re
<t><xref target="Figure1a"></xref> shows an example of a request quest
relayed by a server-domain DOTS gateway.</t> relayed by a server-domain DOTS gateway.</t>
<figure anchor="Figure1a">
<t><figure anchor="Figure1a" <name>PUT for DOTS Mitigation Request as Relayed by a DOTS Gateway</
title="PUT for DOTS Mitigation Request as Relayed by a DOTS Gatewa name>
y"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
... ...
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A server-domain DOTS gateway <bcp14>SHOULD</bcp14> add the followin
<t>A server-domain DOTS gateway SHOULD add the following Uri-Path g Uri-Path
parameter:</t> parameter:</t>
<dl newline="false" spacing="normal" indent="6">
<t><list hangIndent="6" style="hanging"> <dt>cdid:</dt>
<t hangText="cdid:">Stands for Client Domain Identifier. The <dd>
<t>Stands for Client Domain Identifier. The
'cdid' is conveyed by a server-domain DOTS gateway to propagate 'cdid' is conveyed by a server-domain DOTS gateway to propagate
the source domain identity from the gateway's client-facing-side the source domain identity from the gateway's client-facing side
to the gateway's server-facing-side, and from the gateway's to the gateway's server-facing side, and from the gateway's
server-facing-side to the DOTS server. 'cdid' may be used by the server-facing side to the DOTS server. 'cdid' may be used by the
final DOTS server for policy enforcement purposes (e.g., enforce final DOTS server for policy enforcement purposes (e.g., enforce
a quota on filtering rules). These policies are a quota on filtering rules). These policies are
deployment-specific. <vspace blankLines="1" />Server-domain DOTS deployment specific. </t>
gateways SHOULD support a configuration option to instruct <t>Server-domain DOTS
whether 'cdid' parameter is to be inserted. <vspace gateways <bcp14>SHOULD</bcp14> support a configuration option to i
blankLines="1" />In order to accommodate deployments that nstruct
whether 'cdid' parameter is to be inserted. </t>
<t>In order to accommodate deployments that
require enforcing per-client policies, per-client domain require enforcing per-client policies, per-client domain
policies, or a combination thereof, server-domain DOTS gateways policies, or a combination thereof, server-domain DOTS gateways
instructed to insert the 'cdid' parameter MUST supply the SPKI instructed to insert the 'cdid' parameter <bcp14>MUST</bcp14> supp ly the SPKI
hash of the DOTS client X.509 certificate, the DOTS client raw hash of the DOTS client X.509 certificate, the DOTS client raw
public key, or the hash of the "PSK identity" in the 'cdid', public key, or the hash of the "PSK identity" in the 'cdid',
following the same rules for generating the hash conveyed in following the same rules for generating the hash conveyed in
'cuid', which is then used by the ultimate DOTS server to 'cuid', which is then used by the ultimate DOTS server to
determine the corresponding client's domain. The 'cdid' determine the corresponding client's domain.
The 'cdid'
generated by a server-domain gateway is likely to be the same as generated by a server-domain gateway is likely to be the same as
the 'cuid' except if the DOTS message was relayed by a the 'cuid' except the case in which the DOTS message was relayed b y a
client-domain DOTS gateway or the 'cuid' was generated from a client-domain DOTS gateway or the 'cuid' was generated from a
rogue DOTS client. <vspace blankLines="1" />If a DOTS client is rogue DOTS client. </t>
<t>If a DOTS client is
provisioned, for example, with distinct certificates as a provisioned, for example, with distinct certificates as a
function of the peer server-domain DOTS gateway, distinct 'cdid' function of the peer server-domain DOTS gateway, distinct 'cdid'
values may be supplied by a server-domain DOTS gateway. The values may be supplied by a server-domain DOTS gateway. The
ultimate DOTS server MUST treat those 'cdid' values as ultimate DOTS server <bcp14>MUST</bcp14> treat those 'cdid' values
equivalent. <vspace blankLines="1" />The 'cdid' attribute MUST as
NOT be generated and included by DOTS clients. <vspace equivalent. </t>
blankLines="1" />DOTS servers MUST ignore 'cdid' attributes that <t>The 'cdid' attribute <bcp14>MUST
NOT</bcp14> be generated and included by DOTS clients. </t>
<t>DOTS servers <bcp14>MUST</bcp14> ignore 'cdid' attributes that
are directly supplied by source DOTS clients or client-domain are directly supplied by source DOTS clients or client-domain
DOTS gateways. This implies that first server-domain DOTS DOTS gateways. This implies that first server-domain DOTS
gateways MUST strip 'cdid' attributes supplied by DOTS clients. gateways <bcp14>MUST</bcp14> strip 'cdid' attributes supplied by D
DOTS servers SHOULD support a configuration parameter to OTS clients.
DOTS servers <bcp14>SHOULD</bcp14> support a configuration paramet
er to
identify DOTS gateways that are trusted to supply 'cdid' identify DOTS gateways that are trusted to supply 'cdid'
attributes.<vspace blankLines="1" />Only single-valued 'cdid' attributes.</t>
<t>Only single-valued 'cdid'
are defined in this document. That is, only the first on-path are defined in this document. That is, only the first on-path
server-domain DOTS gateway can insert a 'cdid' value. This server-domain DOTS gateway can insert a 'cdid' value. This
specification does not allow multiple server-domain DOTS specification does not allow multiple server-domain DOTS
gateways, whenever involved in the path, to insert a 'cdid' gateways, whenever involved in the path, to insert a 'cdid'
value for each server-domain gateway. <vspace value for each server-domain gateway. </t>
blankLines="1" />This is an optional Uri-Path. When present, <t>This is an optional Uri-Path. When present,
'cdid' MUST be positioned before 'cuid'.</t> 'cdid' <bcp14>MUST</bcp14> be positioned before 'cuid'.</t>
</list></t> </dd>
</dl>
<t>A DOTS gateway SHOULD add the CoAP Hop-Limit Option <xref <t>A DOTS gateway <bcp14>SHOULD</bcp14> add the CoAP Hop-Limit option
target="I-D.ietf-core-hop-limit"></xref>.</t> <xref target="RFC8768" format="default"/>.</t>
<t>Because of the complexity of handling partial failure cases, this
<t>Because of the complexity to handle partial failure cases, this specification does not allow the inclusion of multiple mitigation
specification does not allow for including multiple mitigation requests in the same PUT request. Concretely, a DOTS client <bcp14>MUS
requests in the same PUT request. Concretely, a DOTS client MUST NOT T NOT</bcp14>
include multiple entries in the 'scope' array of the same PUT include multiple entries in the 'scope' array of the same PUT
request.</t> request.</t>
<t>FQDN and URI mitigation scopes may be thought of as a form of <t>FQDN and URI mitigation scopes may be thought of as a form of
scope alias, in which the addresses associated with the domain name scope alias, in which the addresses associated with the domain name
or URI (as resolved by the DOTS server) represent the scope of the or URI (as resolved by the DOTS server) represent the scope of the
mitigation. Particularly, the IP addresses to which the host mitigation. Particularly, the IP addresses to which the host
subcomponent of authority component of an URI resolves represent the subcomponent of authority component of a URI resolves represent the
'target-prefix', the URI scheme represents the 'target-protocol', 'target-prefix', the URI scheme represents the 'target-protocol',
the port subcomponent of authority component of an URI represents the port subcomponent of authority component of a URI represents
the 'target-port-range'. If the optional port information is not the 'target-port-range'. If the optional port information is not
present in the authority component, the default port defined for the present in the authority component, the default port defined for the
URI scheme represents the 'target-port'.</t> URI scheme represents the 'target-port'.</t>
<t>In the PUT request, at least one of the attributes
<t>In the PUT request at least one of the attributes 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' <bcp14>MU
'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST be ST</bcp14> be
present.</t> present.</t>
<t>Attributes and Uri-Path parameters with empty values
<t>Attributes and Uri-Path parameters with empty values MUST NOT be <bcp14>MUST NOT</bcp14> be present in a request as an empty value
present in a request and render the entire request invalid.</t> will render the entire request invalid. </t>
<t> <xref target="Figure2" format="default"/> shows a PUT
<t><xref target="Figure2"></xref> shows a PUT request example to request example to signal that servers 2001:db8:6401::1
signal that TCP port numbers 80, 8080, and 443 used by and 2001:db8:6401::2 are receiving attack traffic on TCP port
2001:db8:6401::1 and 2001:db8:6401::2 servers are under attack. The numbers 80, 8080, and 443.
presence of 'cdid' indicates that a server-domain DOTS gateway has The presence of 'cdid' indicates that a server-domain DOTS gateway has
modified the initial PUT request sent by the DOTS client. Note that modified the initial PUT request sent by the DOTS client. Note that
'cdid' MUST NOT appear in the PUT request message body.</t> 'cdid' <bcp14>MUST NOT</bcp14> appear in the PUT request message body.
</t>
<t><figure anchor="Figure2" <figure anchor="Figure2">
title="PUT for DOTS Mitigation Request (An Example)"> <name>PUT for DOTS Mitigation Request (An Example)</name>
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) <sourcecode><![CDATA[
Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
skipping to change at line 1091 skipping to change at line 980
} }
], ],
"target-protocol": [ "target-protocol": [
6 6
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The corresponding CBOR encoding format for the payload is shown <t>The corresponding CBOR encoding format for the payload is shown
in <xref target="Figure2a"></xref>.</t> in <xref target="Figure2a" format="default"/>.</t>
<figure anchor="Figure2a">
<t><figure anchor="Figure2a" <name>PUT for DOTS Mitigation Request (CBOR)</name>
title="PUT for DOTS Mitigation Request (CBOR)"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[A1 A1 # map(1)
# 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) A4 # map(4)
A3 # map(3) 06 # unsigned(6)
06 # unsigned(6) 82 # array(2)
82 # array(2) 74 # text(20)
74 # text(20) 323030313A6462383A363430313A3A312F313238
323030313A6462383A363430313A3A312F313238 74 # text(20)
74 # text(20) 323030313A6462383A363430313A3A322F313238
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) ]]></sourcecode>
]]></artwork> </figure>
</figure></t>
<t>In both DOTS signal and data channel sessions, the DOTS client <t>In both DOTS signal and data channel sessions, the DOTS client
MUST authenticate itself to the DOTS server (<xref <bcp14>MUST</bcp14> authenticate itself to the DOTS server (<xref targ
target="mutauth"></xref>). The DOTS server MAY use the algorithm et="mutauth" format="default"/>). The DOTS server <bcp14>MAY</bcp14> use the alg
presented in Section 7 of <xref target="RFC7589"></xref> to derive orithm
presented in <xref target="RFC7589" section="7" sectionFormat="of" for
mat="default"/> 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 requests with scopes that the DOTS client is authorized to
manage.</t> manage.</t>
<t>The DOTS server couples the DOTS signal and data channel sessions <t>The DOTS server couples the DOTS signal and data channel sessions
using the DOTS client identity and optionally the 'cdid' parameter using the DOTS client identity and optionally the 'cdid' parameter
value, so the DOTS server can validate whether the aliases conveyed value, so the DOTS server can validate whether the aliases conveyed
in the mitigation request were indeed created by the same DOTS in the mitigation request were indeed created by the same DOTS
client using the DOTS data channel session. If the aliases were not client using the DOTS data channel session. If the aliases were not
created by the DOTS client, the DOTS server MUST return 4.00 (Bad created by the DOTS client, the DOTS server <bcp14>MUST</bcp14> return 4.00 (Bad
Request) in the response.</t> Request) in the response.</t>
<t>The DOTS server couples the DOTS signal channel sessions using <t>The DOTS server couples the DOTS signal channel sessions using
the DOTS client identity and optionally the 'cdid' parameter value, the DOTS client identity and optionally the 'cdid' parameter value,
and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values
to detect duplicate mitigation requests. If the mitigation request to detect duplicate mitigation requests. If the mitigation request
contains the 'alias-name' and other parameters identifying the contains the 'alias-name' and other parameters identifying the
target resources (such as 'target-prefix', 'target-port-range', target resources (such as 'target-prefix', 'target-port-range',
'target-fqdn', or 'target-uri'), the DOTS server appends the 'target-fqdn', or 'target-uri'), the DOTS server appends the
parameter values in 'alias-name' with the corresponding parameter parameter values in 'alias-name' with the corresponding parameter
values in 'target-prefix', 'target-port-range', 'target-fqdn', or values in 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-uri'.</t> 'target-uri'.</t>
skipping to change at line 1157 skipping to change at line 1041
<t>The DOTS server couples the DOTS signal channel sessions using <t>The DOTS server couples the DOTS signal channel sessions using
the DOTS client identity and optionally the 'cdid' parameter value, the DOTS client identity and optionally the 'cdid' parameter value,
and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values
to detect duplicate mitigation requests. If the mitigation request to detect duplicate mitigation requests. If the mitigation request
contains the 'alias-name' and other parameters identifying the contains the 'alias-name' and other parameters identifying the
target resources (such as 'target-prefix', 'target-port-range', target resources (such as 'target-prefix', 'target-port-range',
'target-fqdn', or 'target-uri'), the DOTS server appends the 'target-fqdn', or 'target-uri'), the DOTS server appends the
parameter values in 'alias-name' with the corresponding parameter parameter values in 'alias-name' with the corresponding parameter
values in 'target-prefix', 'target-port-range', 'target-fqdn', or values in 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-uri'.</t> 'target-uri'.</t>
<t>The DOTS server indicates the result of processing the PUT <t>The DOTS server indicates the result of processing the PUT
request using CoAP response codes. CoAP 2.xx codes are success. CoAP request using CoAP Response Codes. CoAP 2.xx codes are success. CoAP
4.xx codes are some sort of invalid requests (client errors). COAP 4.xx codes are some sort of invalid requests (client errors). COAP
5.xx codes are returned if the DOTS server is in an error state or 5.xx codes are returned if the DOTS server is in an error state or
is currently unavailable to provide mitigation in response to the is currently unavailable to provide mitigation in response to the
mitigation request from the DOTS client.</t> mitigation request from the DOTS client.</t>
<t><xref target="put_response" format="default"/> shows an example res
<t><xref target="put_response"></xref> shows an example response to ponse to
a PUT request that is successfully processed by a DOTS server (i.e., a PUT request that is successfully processed by a DOTS server (i.e.,
CoAP 2.xx response codes). This version of the specification forbids CoAP 2.xx Response Codes). This version of the specification forbids
'cuid' and 'cdid' (if used) to be returned in a response message 'cuid' and 'cdid' (if used) to be returned in a response message
body.</t> body.</t>
<figure anchor="put_response">
<t><figure anchor="put_response" title="2.xx Response Body"> <name>2.xx Response Body</name>
<artwork align="left"><![CDATA[{ <sourcecode><![CDATA[
{
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 123, "mid": 123,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>If the request is missing a mandatory attribute, does not include <t>If the request is missing a mandatory attribute, does not include
'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
parameters, or contains invalid or unknown parameters, the DOTS parameters, or contains invalid or unknown parameters, the DOTS
server MUST reply with 4.00 (Bad Request). DOTS agents can safely server <bcp14>MUST</bcp14> reply with 4.00 (Bad Request). DOTS agents can safely
ignore comprehension-optional parameters they don't understand ignore comprehension-optional parameters they don't understand
(<xref target="format"></xref>).</t> (<xref target="format" format="default"/>).</t>
<t>A DOTS server that receives a mitigation request with a 'lifetime'
<t>A DOTS server that receives a mitigation request with a lifetime set to '0' <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request).</t>
set to '0' MUST reply with a 4.00 (Bad Request).</t>
<t>If the DOTS server does not find the 'mid' parameter value <t>If the DOTS server does not find the 'mid' parameter value
conveyed in the PUT request in its configuration data, it MAY accept conveyed in the PUT request in its configuration data, it <bcp14>MAY</ bcp14> accept
the mitigation request by sending back a 2.01 (Created) response to the mitigation request by sending back a 2.01 (Created) response to
the DOTS client; the DOTS server will consequently try to mitigate the DOTS client; the DOTS server will consequently try to mitigate
the attack. A DOTS server could reject mitigation requests when it the attack. A DOTS server could reject mitigation requests when it
is near capacity or needs to rate-limit a particular client, for is near capacity or needs to rate-limit a particular client, for
example.</t> example.</t>
<t>The relative order of two mitigation requests with the same
<t>The relative order of two mitigation requests, having the same 'trigger-mitigation' type from a DOTS client is determined by
'trigger-mitigation' type, from a DOTS client is determined by
comparing their respective 'mid' values. If two mitigation requests comparing their respective 'mid' values. If two mitigation requests
with the same 'trigger-mitigation' type have overlapping mitigation with the same 'trigger-mitigation' type have overlapping mitigation
scopes, the mitigation request with the highest numeric 'mid' value scopes, the mitigation request with the highest numeric 'mid' value
will override the other mitigation request. Two mitigation requests will override the other mitigation request.
from a DOTS client have overlapping scopes if there is a common IP Two mitigation requests from a DOTS client have overlapping
address, IP prefix, FQDN, URI, or alias-name. To avoid maintaining a scopes if there is a common IP address, IP prefix, FQDN, URI,
or alias. To avoid maintaining a
long list of overlapping mitigation requests (i.e., requests with long list of overlapping mitigation requests (i.e., requests with
the same 'trigger-mitigation' type and overlapping scopes) from a the same 'trigger-mitigation' type and overlapping scopes) from a
DOTS client and avoid error-prone provisioning of mitigation DOTS client and to avoid error-prone provisioning of mitigation
requests from a DOTS client, the overlapped lower numeric 'mid' MUST requests from a DOTS client, the overlapped lower numeric 'mid' <bcp14
>MUST</bcp14>
be automatically deleted and no longer available at the DOTS server. be automatically deleted and no longer available at the DOTS server.
For example, if the DOTS server receives a mitigation request which For example, if the DOTS server receives a mitigation request that
overlaps with an existing mitigation with a higher numeric 'mid', overlaps with an existing mitigation with a higher numeric 'mid',
the DOTS server rejects the request by returning 4.09 (Conflict) to the DOTS server rejects the request by returning 4.09 (Conflict) to
the DOTS client. The response includes enough information for a DOTS the DOTS client. The response includes enough information for a DOTS
client to recognize the source of the conflict as described below in client to recognize the source of the conflict as described below in
the 'conflict-information' subtree with only the relevant nodes the 'conflict-information' subtree with only the relevant nodes
listed:</t> listed:</t>
<dl newline="false" spacing="normal">
<t hangText="status:"><list style="hanging"> <dt>conflict-information:</dt>
<t hangText="conflict-information:">Indicates that a mitigation <dd>
<t>Indicates that a mitigation
request is conflicting with another mitigation request. This request is conflicting with another mitigation request. This
optional attribute has the following structure: <list optional attribute has the following structure: </t>
style="hanging"> <dl newline="false" spacing="normal">
<t hangText="conflict-cause:">Indicates the cause of the
conflict. The following values are defined:<list
style="format %d:">
<t>Overlapping targets. 'conflict-scope' provides more
details about the conflicting target clauses.</t>
</list></t>
<t hangText="conflict-scope:">Characterizes the exact
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 a 'mid'.</t>
</list></t>
</list></t>
<t>If the DOTS server receives a mitigation request which overlaps <dt>conflict-cause:</dt>
with an active mitigation request, but both having distinct <dd>
'trigger-mitigation' types, the DOTS server SHOULD deactivate <t>Indicates the cause of the
conflict. The following values are defined:</t>
<dl spacing="normal">
<dt>1:</dt>
<dd>Overlapping targets. 'conflict-scope' provides more
details about the conflicting target clauses.</dd>
</dl>
</dd>
<dt>conflict-scope:</dt>
<dd>Characterizes the exact
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 aliases, or a 'mid'.
</dd>
</dl>
</dd>
</dl>
<t>If the DOTS server receives a mitigation request that overlaps
with an active mitigation request, but both have distinct
'trigger-mitigation' types, the DOTS server <bcp14>SHOULD</bcp14> deac
tivate
(absent explicit policy/configuration otherwise) the mitigation (absent explicit policy/configuration otherwise) the mitigation
request with 'trigger-mitigation' set to false. Particularly, if the request with 'trigger-mitigation' set to 'false'. Particularly, if the
mitigation request with 'trigger-mitigation' set to false is active, mitigation request with 'trigger-mitigation' set to 'false' is active,
the DOTS server withdraws the mitigation request (i.e., status code the DOTS server withdraws the mitigation request (i.e., status code
is set to '7' as defined in <xref target="status"></xref>) and is set to '7' as defined in <xref target="status" format="default"/>) and
transitions the status of the mitigation request to '8'.</t> transitions the status of the mitigation request to '8'.</t>
<t>Upon DOTS signal channel session loss with a peer DOTS client, <t>Upon DOTS signal channel session loss with a peer DOTS client,
the DOTS server SHOULD withdraw (absent explicit the DOTS server <bcp14>SHOULD</bcp14> withdraw (absent explicit
policy/configuration otherwise) any active mitigation requests policy/configuration otherwise) any active mitigation requests
overlapping with mitigation requests having 'trigger-mitigation' set that overlap with mitigation requests having 'trigger-mitigation' set
to false from that DOTS client, as the loss of the session to 'false' from that DOTS client, as the loss of the session
implicitly activates these preconfigured mitigation requests and implicitly activates these preconfigured mitigation requests, and
they take precedence. Note that active-but-terminating period is not they take precedence. Note that the active-but-terminating period is n
ot
observed for mitigations withdrawn at the initiative of the DOTS observed for mitigations withdrawn at the initiative of the DOTS
server.</t> server.</t>
<t>DOTS clients may adopt various strategies for setting the scopes <t>DOTS clients may adopt various strategies for setting the scopes
of immediate and pre-configured mitigation requests to avoid of immediate and preconfigured mitigation requests to avoid
potential conflicts. For example, a DOTS client may tweak potential conflicts. For example, a DOTS client may tweak
pre-configured scopes so that the scope of any overlapping immediate preconfigured scopes so that the scope of any overlapping immediate
mitigation request will be a subset of the pre-configured scopes. mitigation request will be a subset of the preconfigured scopes.
Also, if an immediate mitigation request overlaps with any of the Also, if an immediate mitigation request overlaps with any of the
pre-configured scopes, the DOTS client sets the scope of the preconfigured scopes, the DOTS client sets the scope of the
overlapping immediate mitigation request to be a subset of the overlapping immediate mitigation request to be a subset of the
pre-configured scopes, so as to get a broad mitigation when the DOTS preconfigured scopes, so as to get a broad mitigation when the DOTS
signal channel collapses and maximize the chance of recovery.</t> signal channel collapses and to maximize the chance of recovery.</t>
<t>If the request conflicts with an existing mitigation request
<t>If the request is conflicting with an existing mitigation request
from a different DOTS client, the DOTS server may return 2.01 from a different DOTS client, the DOTS server may return 2.01
(Created) or 4.09 (Conflict) to the requesting DOTS client. If the (Created) or 4.09 (Conflict) to the requesting DOTS client. If the
DOTS server decides to maintain the new mitigation request, the DOTS DOTS server decides to maintain the new mitigation request, the DOTS
server returns 2.01 (Created) to the requesting DOTS client. If the server returns 2.01 (Created) to the requesting DOTS client. If the
DOTS server decides to reject the new mitigation request, the DOTS DOTS server decides to reject the new mitigation request, the DOTS
server returns 4.09 (Conflict) to the requesting DOTS client. For server returns 4.09 (Conflict) to the requesting DOTS client. For
both 2.01 (Created) and 4.09 (Conflict) responses, the response both 2.01 (Created) and 4.09 (Conflict) responses, the response
includes enough information for a DOTS client to recognize the includes enough information for a DOTS client to recognize the
source of the conflict as described below:</t> source of the conflict as described below:</t>
<t hangText="status:"><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="conflict-information:">Indicates that a mitigation <dt>conflict-information:</dt>
<dd>
<t>Indicates that a mitigation
request is conflicting with another mitigation request(s) from request is conflicting with another mitigation request(s) from
other DOTS client(s). This optional attribute has the following other DOTS client(s). This optional attribute has the following
structure: <list style="hanging"> structure: </t>
<t hangText="conflict-status:">Indicates the status of a <dl newline="false" spacing="normal">
<dt>conflict-status:</dt>
<dd>
<t>Indicates the status of a
conflicting mitigation request. The following values are conflicting mitigation request. The following values are
defined:<list style="format %d:"> defined:</t>
<t>DOTS server has detected conflicting mitigation <dl spacing="normal">
<dt>1:</dt>
<dd>DOTS server has detected conflicting mitigation
requests from different DOTS clients. This mitigation requests from different DOTS clients. This mitigation
request is currently inactive until the conflicts are request is currently inactive until the conflicts are
resolved. Another mitigation request is active.</t> resolved. Another mitigation request is active.</dd>
<dt>2:</dt>
<t>DOTS server has detected conflicting mitigation <dd>DOTS server has detected conflicting mitigation
requests from different DOTS clients. This mitigation requests from different DOTS clients. This mitigation
request is currently active.</t> request is currently active.</dd>
<dt>3:</dt>
<t>DOTS server has detected conflicting mitigation <dd>DOTS server has detected conflicting mitigation
requests from different DOTS clients. All conflicting requests from different DOTS clients. All conflicting
mitigation requests are inactive.</t> mitigation requests are inactive.</dd>
</list></t> </dl>
</dd>
<t hangText="conflict-cause:">Indicates the cause of the <dt>conflict-cause:</dt>
conflict. The following values are defined:<list <dd>
style="format %d:"> <t>Indicates the cause of the
<t>Overlapping targets. 'conflict-scope' provides more conflict. The following values are defined:</t>
details about the conflicting target clauses.</t> <dl spacing="normal">
<dt>1:</dt>
<t>Conflicts with an existing accept-list. This code is <dd>Overlapping targets. 'conflict-scope' provides more
details about the conflicting target clauses.</dd>
<dt>2:</dt>
<dd>Conflicts with an existing accept-list. This code is
returned when the DDoS mitigation detects source returned when the DDoS mitigation detects source
addresses/prefixes in the accept-listed ACLs are addresses/prefixes in the accept-listed ACLs are
attacking the target.</t> attacking the target.</dd>
<dt>3:</dt>
<t>CUID Collision. This code is returned when a DOTS <dd>CUID Collision. This code is returned when a DOTS
client uses a 'cuid' that is already used by another client uses a 'cuid' that is already used by another
DOTS client. This code is an indication that the request DOTS client. This code is an indication that the request
has been rejected and a new request with a new 'cuid' is has been rejected and a new request with a new 'cuid' is
to be re-sent by the DOTS client (see the example shown to be re-sent by the DOTS client (see the example shown
in <xref target="newcuid"></xref>). Note that in <xref target="newcuid" format="default"/>). Note that
'conflict-status', 'conflict-scope', and 'retry-timer' 'conflict-status', 'conflict-scope', and 'retry-timer'
MUST NOT be returned in the error response.</t> <bcp14>MUST NOT</bcp14> be returned in the error response.
</list></t> </dd>
</dl>
<t hangText="conflict-scope:">Characterizes the exact </dd>
<dt>conflict-scope:</dt>
<dd>Characterizes the exact
conflict scope. It may include a list of IP addresses, a conflict scope. It may include a list of IP addresses, a
list of prefixes, a list of port numbers, a list of target list of prefixes, a list of port numbers, a list of target
protocols, a list of FQDNs, a list of URIs, a list of protocols, a list of FQDNs, a list of URIs, a list of
alias-names, or references to conflicting ACLs (by an aliases, or references to conflicting ACLs (by an
'acl-name', typically <xref 'acl-name', typically <xref target="RFC8783" format="default"/
target="I-D.ietf-dots-data-channel"></xref>).</t> >).</dd>
<dt>retry-timer:</dt>
<t hangText="retry-timer:">Indicates, in seconds, the time <dd>
after which the DOTS client may re-issue the same request. <t>Indicates, in seconds, the time
after which the DOTS client may reissue the same request.
The DOTS server returns 'retry-timer' only to DOTS client(s) The DOTS server returns 'retry-timer' only to DOTS client(s)
for which a mitigation request is deactivated. Any for which a mitigation request is deactivated. Any
retransmission of the same mitigation request before the retransmission of the same mitigation request before the
expiry of this timer is likely to be rejected by the DOTS expiry of this timer is likely to be rejected by the DOTS
server for the same reasons.<vspace blankLines="1" />The server for the same reasons.</t>
retry-timer SHOULD be equal to the lifetime of the active <t>The
'retry-timer' <bcp14>SHOULD</bcp14> be equal to the lifetime o
f the active
mitigation request resulting in the deactivation of the mitigation request resulting in the deactivation of the
conflicting mitigation request. <vspace blankLines="1" />If conflicting mitigation request. </t>
<t>If
the DOTS server decides to maintain a state for the the DOTS server decides to maintain a state for the
deactivated mitigation request, the DOTS server updates the deactivated mitigation request, the DOTS server updates the
lifetime of the deactivated mitigation request to lifetime of the deactivated mitigation request to
'retry-timer + 45 seconds' (that is, this mitigation request 'retry-timer + 45 seconds' (that is, this mitigation request
remains deactivated for the entire duration of 'retry-timer remains deactivated for the entire duration of 'retry-timer
+ 45 seconds') so that the DOTS client can refresh the + 45 seconds') so that the DOTS client can refresh the
deactivated mitigation request after 'retry-timer' seconds, deactivated mitigation request after 'retry-timer' seconds,
but before the expiry of the lifetime, and check if the but before the expiry of the lifetime, and check if the
conflict is resolved.</t> conflict is resolved.</t>
</list></t> </dd>
</list></t> </dl>
</dd>
<t hangText="conflict-information:"><figure align="center" </dl>
anchor="newcuid" title="Example of Generating a New 'cuid'"> <figure anchor="newcuid">
<artwork><![CDATA[ Header: PUT (Code=0.03) <name>Example of Generating a New 'cuid'</name>
<sourcecode><![CDATA[
Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=7eeaf349529eb55ed50113" Uri-Path: "cuid=7eeaf349529eb55ed50113"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(1) Request with a conflicting 'cuid' (1) Request with a conflicting 'cuid'
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
skipping to change at line 1391 skipping to change at line 1291
(2) Message body of the 4.09 (Conflict) response (2) Message body of the 4.09 (Conflict) response
from the DOTS server from the DOTS server
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(3) Request with a new 'cuid']]></artwork> (3) Request with a new 'cuid']]></sourcecode>
</figure></t> </figure>
<t>As an active attack evolves,
<t hangText="conflict-information:">As an active attack evolves,
DOTS clients can adjust the scope of requested mitigation as DOTS clients can adjust the scope of requested mitigation as
necessary, by refining the scope of resources requiring mitigation. necessary, by refining the scope of resources requiring mitigation.
This can be achieved by sending a PUT request with a new 'mid' value This can be achieved by sending a PUT request with a new 'mid' value
that will override the existing one with overlapping mitigation that will override the existing one with overlapping mitigation
scopes.</t> scopes.</t>
<t>For a mitigation request to
<t hangText="conflict-information:">For a mitigation request to
continue beyond the initial negotiated lifetime, the DOTS client has continue beyond the initial negotiated lifetime, the DOTS client has
to refresh the current mitigation request by sending a new PUT to refresh the current mitigation request by sending a new PUT
request. This PUT request MUST use the same 'mid' value, and MUST request. This PUT request <bcp14>MUST</bcp14> use the same
'mid' value, and it <bcp14>MUST</bcp14>
repeat all the other parameters as sent in the original mitigation repeat all the other parameters as sent in the original mitigation
request apart from a possible change to the lifetime parameter request apart from a possible change to the 'lifetime' parameter
value. In such case, the DOTS server MAY update the mitigation value. In such a case, the DOTS server <bcp14>MAY</bcp14> update the m
itigation
request, and a 2.04 (Changed) response is returned to indicate a request, and a 2.04 (Changed) response is returned to indicate a
successful update of the mitigation request. If this is not the successful update of the mitigation request. If this is not the
case, the DOTS server MUST reject the request with a 4.00 (Bad case, the DOTS server <bcp14>MUST</bcp14> reject the request with a 4. 00 (Bad
Request).</t> Request).</t>
</section> </section>
<section anchor="get" numbered="true" toc="default">
<section anchor="get" <name>Retrieve Information Related to a Mitigation</name>
title="Retrieve Information Related to a Mitigation">
<t>A GET request is used by a DOTS client to retrieve information <t>A GET request is used by a DOTS client to retrieve information
(including status) of DOTS mitigations from a DOTS server.</t> (including status) of DOTS mitigations from a DOTS server.</t>
<t>'cuid' is a mandatory Uri-Path parameter for GET requests.</t> <t>'cuid' is a mandatory Uri-Path parameter for GET requests.</t>
<t>Uri-Path parameters with empty values <bcp14>MUST NOT</bcp14> be pr
<t>Uri-Path parameters with empty values MUST NOT be present in a esent in a
request.</t> request.</t>
<t>The same considerations for manipulating the 'cdid' parameter by
<t>The same considerations for manipulating 'cdid' parameter by server-domain DOTS gateways specified in <xref target="post" format="d
server-domain DOTS gateways specified in <xref target="post"></xref> efault"/>
MUST be followed for GET requests.</t> <bcp14>MUST</bcp14> be followed for GET requests.</t>
<t>The 'c' Uri-Query option is used to control selection of <t>The 'c' Uri-Query option is used to control selection of
configuration and non-configuration data nodes. Concretely, the 'c' configuration and non-configuration data nodes. Concretely, the 'c'
(content) parameter and its permitted values defined in the (content) parameter and its permitted values defined in
following table <xref target="I-D.ietf-core-comi"></xref> can be <xref target="tab-option-controls" format="default"/> <xref target="I-
D.ietf-core-comi" format="default"/> can be
used to retrieve non-configuration data (attack mitigation status), used to retrieve non-configuration data (attack mitigation status),
configuration data, or both. The DOTS server MAY support this configuration data, or both. The DOTS server <bcp14>MAY</bcp14> suppor t this
optional filtering capability. It can safely ignore it if not optional filtering capability. It can safely ignore it if not
supported. If the DOTS client supports the optional filtering supported. If the DOTS client supports the optional filtering
capability, it SHOULD use "c=n" query (to get back only the capability, it <bcp14>SHOULD</bcp14> use "c=n" query (to get back only the
dynamically changing data) or "c=c" query (to get back the static dynamically changing data) or "c=c" query (to get back the static
configuration values) when the DDoS attack is active to limit the configuration values) when the DDoS attack is active to limit the
size of the response.</t> size of the response.</t>
<table anchor="tab-option-controls" align="center">
<texttable> <name>Permitted Values of the 'c' Parameter</name>
<ttcol>Value</ttcol> <thead>
<tr>
<ttcol>Description</ttcol> <th align="left">Value</th>
<th align="left">Description</th>
<c>c</c> </tr>
</thead>
<c>Return only configuration descendant data nodes</c> <tbody>
<tr>
<c>n</c> <td align="left">c</td>
<td align="left">Return only configuration descendant data nodes
<c>Return only non-configuration descendant data nodes</c> </td>
</tr>
<c>a</c> <tr>
<td align="left">n</td>
<c>Return all descendant data nodes</c> <td align="left">Return only non-configuration descendant data n
</texttable> odes</td>
</tr>
<t>The DOTS client can use Block-wise transfer <xref <tr>
target="RFC7959"></xref> to get the list of all its mitigations <td align="left">a</td>
maintained by a DOTS server, it can send Block2 Option in a GET <td align="left">Return all descendant data nodes</td>
</tr>
</tbody>
</table>
<t>The DOTS client can use block-wise transfer <xref target="RFC7959"
format="default"/> to get the list of all its mitigations
maintained by a DOTS server, it can send a Block2 Option in a GET
request with NUM = 0 to aid in limiting the size of the response. If request with NUM = 0 to aid in limiting the size of the response. If
the representation of all the active mitigation requests associated the representation of all the active mitigation requests associated
with the DOTS client does not fit within a single datagram, the DOTS with the DOTS client does not fit within a single datagram, the DOTS
server MUST use the Block2 Option with NUM = 0 in the GET response. server <bcp14>MUST</bcp14> use the Block2 Option with NUM = 0 in the G ET response.
The Size2 Option may be conveyed in the response to indicate the The Size2 Option may be conveyed in the response to indicate the
total size of the resource representation. The DOTS client retrieves total size of the resource representation. The DOTS client retrieves
the rest of the representation by sending additional GET requests the rest of the representation by sending additional GET requests
with Block2 Options containing NUM values greater than zero. The with Block2 Options containing NUM values greater than zero. The
DOTS client MUST adhere to the block size preferences indicated by DOTS client <bcp14>MUST</bcp14> adhere to the block size preferences i ndicated by
the DOTS server in the response. If the DOTS server uses the Block2 the DOTS server in the response. If the DOTS server uses the Block2
Option in the GET response and the response is for a dynamically Option in the GET response, and the response is for a dynamically
changing resource (e.g., "c=n" or "c=a" query), the DOTS server MUST changing resource (e.g., "c=n" or "c=a" query), the DOTS server <bcp14
include the ETag Option in the response. The DOTS client MUST >MUST</bcp14>
include the ETag Option in the response. The DOTS client <bcp14>MUST</
bcp14>
include the same ETag value in subsequent GET requests to retrieve include the same ETag value in subsequent GET requests to retrieve
the rest of the representation.</t> the rest of the representation.</t>
<t>The following examples illustrate how a DOTS client retrieves <t>The following examples illustrate how a DOTS client retrieves
active mitigation requests from a DOTS server. In particular: <list active mitigation requests from a DOTS server. In particular: </t>
style="symbols"> <ul spacing="normal">
<t><xref target="Figure4"></xref> shows the example of a GET <li>
<xref target="Figure4" format="default"/> shows the example of a G
ET
request to retrieve all DOTS mitigation requests signaled by a request to retrieve all DOTS mitigation requests signaled by a
DOTS client.</t> DOTS client.</li>
<li>
<t><xref target="Figure4a"></xref> shows the example of a GET <xref target="Figure4a" format="default"/> shows the example of a
GET
request to retrieve a specific DOTS mitigation request signaled request to retrieve a specific DOTS mitigation request signaled
by a DOTS client. The configuration data to be reported in the by a DOTS client. The configuration data to be reported in the
response is formatted in the same order as was processed by the response is formatted in the same order as it was processed by the
DOTS server in the original mitigation request.</t> DOTS server in the original mitigation request.</li>
</list></t> </ul>
<t>These two examples assume the default of "c=a"; that is, the DOTS <t>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.</t> client asks for all data to be reported by the DOTS server.</t>
<figure anchor="Figure4">
<figure anchor="Figure4" <name>GET to Retrieve All DOTS Mitigation Requests</name>
title="GET to Retrieve all DOTS Mitigation Requests"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0]]></artwork> Observe: 0
]]></sourcecode>
</figure> </figure>
<figure anchor="Figure4a">
<t><figure anchor="Figure4a" <name>GET to Retrieve a Specific DOTS Mitigation Request</name>
title="GET to Retrieve a Specific DOTS Mitigation Request"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Observe: 0 Observe: 0
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>If the DOTS server does not find the 'mid' Uri-Path value <t>If the DOTS server does not find the 'mid' Uri-Path value
conveyed in the GET request in its configuration data for the conveyed in the GET request in its configuration data for the
requesting DOTS client, it MUST respond with a 4.04 (Not Found) requesting DOTS client, it <bcp14>MUST</bcp14> respond with a 4.04 (No
error response code. Likewise, the same error MUST be returned as a t Found)
error Response Code. Likewise, the same error <bcp14>MUST</bcp14> be r
eturned as a
response to a request to retrieve all mitigation records (i.e., response to a request to retrieve all mitigation records (i.e.,
'mid' Uri-Path is not defined) of a given DOTS client if the DOTS 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS
server does not find any mitigation record for that DOTS client. As server does not find any mitigation record for that DOTS client. As
a reminder, a DOTS client is identified by its identity (e.g., a reminder, a DOTS client is identified by its identity (e.g.,
client certificate, 'cuid') and optionally the 'cdid'.</t> client certificate, 'cuid') and optionally the 'cdid'.</t>
<t><xref target="Figure5" format="default"/> shows a response example
<t><xref target="Figure5"></xref> shows a response example of all of all
active mitigation requests associated with the DOTS client as active mitigation requests associated with the DOTS client as
maintained by the DOTS server. The response indicates the mitigation maintained by the DOTS server. The response indicates the mitigation
status of each mitigation request.</t> status of each mitigation request.</t>
<figure anchor="Figure5">
<t><figure anchor="Figure5" title="Response Body to a GET Request"> <name>Response Body to a GET Request</name>
<artwork align="left"><![CDATA[{ <sourcecode><![CDATA[
{
"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": [
skipping to change at line 1572 skipping to change at line 1468
], ],
"lifetime": 1755, "lifetime": 1755,
"status": "attack-stopped", "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"
} }
] ]
} }
}]]></artwork> }]]></sourcecode>
</figure></t> </figure>
<t>The mitigation status parameters are described below:</t> <t>The mitigation status parameters are described below:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>mitigation-start:</dt>
<t hangText="mitigation-start:">Mitigation start time is <dd>
<t>Mitigation start time is
expressed in seconds relative to 1970-01-01T00:00Z in UTC time expressed in seconds relative to 1970-01-01T00:00Z in UTC time
(Section 2.4.1 of <xref target="RFC7049"></xref>). The CBOR (<xref target="RFC7049" section="2.4.1" sectionFormat="of" format= "default"/>). The CBOR
encoding is modified so that the leading tag 1 (epoch-based encoding is modified so that the leading tag 1 (epoch-based
date/time) MUST be omitted.<vspace blankLines="1" />This is a date/time) <bcp14>MUST</bcp14> be omitted.</t>
<t>This is a
mandatory attribute when an attack mitigation is active. mandatory attribute when an attack mitigation is active.
Particularly, 'mitigation-start' is not returned for a Particularly, 'mitigation-start' is not returned for a
mitigation with 'status' code set to 8.</t> mitigation with 'status' code set to 8.</t>
</dd>
<t hangText="lifetime:">The remaining lifetime of the mitigation <dt>lifetime:</dt>
request, in seconds.<vspace blankLines="1" />This is a mandatory <dd>
<t>The remaining lifetime of the mitigation
request, in seconds.</t>
<t>This is a mandatory
attribute.</t> attribute.</t>
</dd>
<t hangText="status:">Status of attack mitigation. The various <dt>status:</dt>
possible values of 'status' parameter are explained in <xref <dd>
target="status"></xref>.<vspace blankLines="1" />This is a <t>Status of attack mitigation. The various
possible values of 'status' parameter are explained in <xref targe
t="status" format="default"/>.</t>
<t>This is a
mandatory attribute.</t> mandatory attribute.</t>
</dd>
<t hangText="bytes-dropped:">The total dropped byte count for <dt>bytes-dropped:</dt>
the mitigation request since the attack mitigation is triggered. <dd>
<t>The total dropped byte count for
the mitigation request since the attack mitigation was triggered.
The count wraps around when it reaches the maximum value of The count wraps around when it reaches the maximum value of
unsigned integer64. <vspace blankLines="1" />This is an optional unsigned integer64. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="bps-dropped:">The average number of dropped bytes <dt>bps-dropped:</dt>
<dd>
<t>The average number of dropped bytes
per second for the mitigation request since the attack per second for the mitigation request since the attack
mitigation is triggered. This average SHOULD be over five-minute mitigation was triggered. This average <bcp14>SHOULD</bcp14> be ov er five-minute
intervals (that is, measuring bytes into five-minute buckets and intervals (that is, measuring bytes into five-minute buckets and
then averaging these buckets over the time since the mitigation then averaging these buckets over the time since the mitigation
was triggered). <vspace blankLines="1" />This is an optional was triggered). </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="pkts-dropped:">The total number of dropped packet <dt>pkts-dropped:</dt>
count for the mitigation request since the attack mitigation is <dd>
<t>The total number of dropped packet
count for the mitigation request since the attack mitigation was
triggered. The count wraps around when it reaches the maximum triggered. The count wraps around when it reaches the maximum
value of unsigned integer64.<vspace blankLines="1" />This is an value of unsigned integer64.</t>
<t>This is an
optional attribute.</t> optional attribute.</t>
</dd>
<t hangText="pps-dropped:">The average number of dropped packets <dt>pps-dropped:</dt>
<dd>
<t>The average number of dropped packets
per second for the mitigation request since the attack per second for the mitigation request since the attack
mitigation is triggered. This average SHOULD be over five-minute mitigation was triggered. This average <bcp14>SHOULD</bcp14> be ov er five-minute
intervals (that is, measuring packets into five-minute buckets intervals (that is, measuring packets into five-minute buckets
and then averaging these buckets over the time since the and then averaging these buckets over the time since the
mitigation was triggered).<vspace blankLines="1" />This is an mitigation was triggered).</t>
<t>This is an
optional attribute.</t> optional attribute.</t>
</list></t> </dd>
</dl>
<t></t> <table anchor="status" align="center">
<name>Values of 'status' Parameter</name>
<texttable anchor="status" style="all" <thead>
title=" Values of 'status' Parameter"> <tr>
<ttcol align="right">Parameter Value</ttcol> <th align="right">Parameter Value</th>
<th align="left">Description</th>
<ttcol align="left">Description</ttcol> </tr>
</thead>
<c>1</c> <tbody>
<tr>
<c>Attack mitigation setup is in progress (e.g., changing the <td align="right">1</td>
<td align="left">Attack mitigation setup is in progress (e.g., c
hanging the
network path to redirect the inbound traffic to a DOTS network path to redirect the inbound traffic to a DOTS
mitigator).</c> mitigator).</td>
</tr>
<c>2</c> <tr>
<td align="right">2</td>
<c>Attack is being successfully mitigated (e.g., traffic is <td align="left">Attack is being successfully mitigated (e.g., t
redirected to a DDoS mitigator and attack traffic is dropped).</c> raffic is
redirected to a DDoS mitigator and attack traffic is dropped).</td>
<c>3</c> </tr>
<tr>
<c>Attack has stopped and the DOTS client can withdraw the <td align="right">3</td>
<td align="left">Attack has stopped and the DOTS client can with
draw the
mitigation request. This status code will be transmitted for mitigation request. This status code will be transmitted for
immediate mitigation requests till the mitigation is withdrawn or immediate mitigation requests till the mitigation is withdrawn or
the lifetime expires. For mitigation requests with pre-configured the lifetime expires. For mitigation requests with preconfigured
scopes (i.e., 'trigger-mitigation' set to 'false'), this status scopes (i.e., 'trigger-mitigation' set to 'false'), this status
code will be transmitted 4 times and then transition to "8".</c> code will be transmitted four times and then transition to "8".</td>
</tr>
<c>4</c> <tr>
<td align="right">4</td>
<c>Attack has exceeded the mitigation provider capability.</c> <td align="left">Attack has exceeded the mitigation provider cap
ability.</td>
<c>5</c> </tr>
<tr>
<c>DOTS client has withdrawn the mitigation request and the <td align="right">5</td>
mitigation is active but terminating.</c> <td align="left">DOTS client has withdrawn the mitigation reques
t and the
<c>6</c> mitigation is active but terminating.</td>
</tr>
<c>Attack mitigation is now terminated.</c> <tr>
<td align="right">6</td>
<c>7</c> <td align="left">Attack mitigation is now terminated.</td>
</tr>
<c>Attack mitigation is withdrawn (by the DOTS server). If a <tr>
mitigation request with 'trigger-mitigation' set to false is <td align="right">7</td>
<td align="left">Attack mitigation is withdrawn (by the DOTS ser
ver). If a
mitigation request with 'trigger-mitigation' set to 'false' is
withdrawn because it overlaps with an immediate mitigation withdrawn because it overlaps with an immediate mitigation
request, this status code will be transmitted 4 times and then request, this status code will be transmitted four times and then
transition to "8" for the mitigation request with pre-configured transition to "8" for the mitigation request with preconfigured
scopes.</c> scopes.</td>
</tr>
<c>8</c> <tr>
<td align="right">8</td>
<c>Attack mitigation will be triggered for the mitigation request <td align="left">Attack mitigation will be triggered for the mit
only when the DOTS signal channel session is lost.</c> igation request
</texttable> only when the DOTS signal channel session is lost.</td>
</tr>
<t></t> </tbody>
</table>
<section title="DOTS Servers Sending Mitigation Status"> <section numbered="true" toc="default">
<t>The Observe Option defined in <xref target="RFC7641"></xref> <name>DOTS Servers Sending Mitigation Status</name>
<t>The Observe Option defined in <xref target="RFC7641" format="defa
ult"/>
extends the CoAP core protocol with a mechanism for a CoAP client extends the CoAP core protocol with a mechanism for a CoAP client
to "observe" a resource on a CoAP server: The client retrieves a to "observe" a resource on a CoAP server: the client retrieves a
representation of the resource and requests this representation be representation of the resource and requests this representation be
updated by the server as long as the client is interested in the updated by the server as long as the client is interested in the
resource. DOTS implementations MUST use the Observe Option for resource. DOTS implementations <bcp14>MUST</bcp14> use the Observe O
both 'mitigate' and 'config' (<xref ption for
target="uri-path"></xref>).</t> both 'mitigate' and 'config' (<xref target="uri-path" format="defaul
t"/>).</t>
<t>A DOTS client conveys the Observe Option set to '0' in the GET <t>A DOTS client conveys the Observe Option set to '0' in the GET
request to receive asynchronous notifications of attack mitigation request to receive asynchronous notifications of attack mitigation
status from the DOTS server.</t> status from the DOTS server.</t>
<t>Unidirectional mitigation notifications within the <t>Unidirectional mitigation notifications within the
bidirectional signal channel enables asynchronous notifications bidirectional signal channel enables asynchronous notifications
between the agents. <xref target="RFC7641"></xref> indicates that between the agents. <xref target="RFC7641" format="default"/> indica tes that
(1) a notification can be sent in a Confirmable or a (1) a notification can be sent in a Confirmable or a
Non-confirmable message, and (2) the message type used is Non-confirmable message, and (2) the message type used is
typically application-dependent and may be determined by the typically application dependent and may be determined by the
server for each notification individually. For DOTS server server for each notification individually. For the DOTS server
application, the message type MUST always be set to application, the message type <bcp14>MUST</bcp14> always be set to
Non-confirmable even if the underlying COAP library elects a Non-confirmable even if the underlying COAP library elects a
notification to be sent in a Confirmable message. This overrides notification to be sent in a Confirmable message. This overrides
the behavior defined in Section 4.5 of <xref the behavior defined in <xref target="RFC7641" section="4.5" section
target="RFC7641"></xref> to send a Confirmable message instead of Format="of" format="default"/> to send a Confirmable message instead of
a Non-confirmable message at least every 24 hour for the following a Non-confirmable message at least every 24 hours for the following
reasons: First, the DOTS signal channel uses a heartbeat mechanism reasons: First, the DOTS signal channel uses a heartbeat mechanism
to determine if the DOTS client is alive. Second, Confirmable to determine if the DOTS client is alive. Second, Confirmable
messages are not suitable during an attack.</t> messages are not suitable during an attack.</t>
<t>Due to the higher likelihood of packet loss during a DDoS <t>Due to the higher likelihood of packet loss during a DDoS
attack, the DOTS server periodically sends attack mitigation attack, the DOTS server periodically sends attack mitigation
status to the DOTS client and also notifies the DOTS client status to the DOTS client and also notifies the DOTS client
whenever the status of the attack mitigation changes. If the DOTS whenever the status of the attack mitigation changes. If the DOTS
server cannot maintain an RTT estimate, it MUST NOT send more than server cannot maintain an RTT estimate, it <bcp14>MUST NOT</bcp14> s
one asynchronous notification every 3 seconds, and SHOULD use an end more than
even less aggressive rate whenever possible (case 2 in Section one asynchronous notification every 3 seconds, and <bcp14>SHOULD</bc
3.1.3 of <xref target="RFC8085"></xref>).</t> p14> use an
even less aggressive rate whenever possible (case 2 in
<t><!--The DOTS server MUST use the same CUID as the one used by the <xref target="RFC8085" section="3.1.3" sectionFormat="of" format="de
DOTS client to observe a mitigation request.-->When fault"/>).</t>
conflicting requests are detected, the DOTS server enforces the <t>When conflicting requests are detected, the DOTS server enforces
the
corresponding policy (e.g., accept all requests, reject all corresponding policy (e.g., accept all requests, reject all
requests, accept only one request but reject all the others, ...). requests, accept only one request but reject all the others, etc.).
It is assumed that this policy is supplied by the DOTS server It is assumed that this policy is supplied by the DOTS server
administrator or it is a default behavior of the DOTS server administrator or that it is a default behavior of the DOTS server
implementation. Then, the DOTS server sends notification implementation. Then, the DOTS server sends a notification
message(s) to the DOTS client(s) at the origin of the conflict message(s) to the DOTS client(s) at the origin of the conflict
(refer to the conflict parameters defined in <xref (refer to the conflict parameters defined in <xref target="post" for
target="post"></xref>). A conflict notification message includes mat="default"/>). A conflict notification message includes
information about the conflict cause, scope, and the status of the information about the conflict cause, scope, and the status of the
mitigation request(s). For example,<list style="symbols"> mitigation request(s). For example:</t>
<t>A notification message with 'status' code set to '7 (Attack <ul spacing="normal">
<li>A notification message with 'status' code set to '7 (Attack
mitigation is withdrawn)' and 'conflict-status' set to '1' is mitigation is withdrawn)' and 'conflict-status' set to '1' is
sent to a DOTS client to indicate that an active mitigation sent to a DOTS client to indicate that an active mitigation
request is deactivated because a conflict is detected.</t> request is deactivated because a conflict is detected.</li>
<li>A notification message with 'status' code set to '1 (Attack
<t>A notification message with 'status' code set to '1 (Attack
mitigation is in progress)' and 'conflict-status' set to '2' mitigation is in progress)' and 'conflict-status' set to '2'
is sent to a DOTS client to indicate that this mitigation is sent to a DOTS client to indicate that this mitigation
request is in progress, but a conflict is detected.</t> request is in progress, but a conflict is detected.</li>
</list></t> </ul>
<t>Upon receipt of a conflict notification message indicating that <t>Upon receipt of a conflict notification message indicating that
a mitigation request is deactivated because of a conflict, a DOTS a mitigation request is deactivated because of a conflict, a DOTS
client MUST NOT resend the same mitigation request before the client <bcp14>MUST NOT</bcp14> resend the same mitigation request be fore the
expiry of 'retry-timer'. It is also recommended that DOTS clients expiry of 'retry-timer'. It is also recommended that DOTS clients
support means to alert administrators about mitigation support the means to alert administrators about mitigation
conflicts.</t> conflicts.</t>
<t>A DOTS client that is no longer interested in receiving <t>A DOTS client that is no longer interested in receiving
notifications from the DOTS server can simply "forget" the notifications from the DOTS server can simply "forget" the
observation. When the DOTS server sends the next notification, the observation. When the DOTS server sends the next notification, the
DOTS client will not recognize the token in the message and thus DOTS client will not recognize the token in the message and, thus,
will return a Reset message. This causes the DOTS server to remove will return a Reset message. This causes the DOTS server to remove
the associated entry. Alternatively, the DOTS client can the associated entry. Alternatively, the DOTS client can
explicitly deregister itself by issuing a GET request that has the explicitly de-register itself by issuing a GET request that has the
Token field set to the token of the observation to be cancelled Token field set to the token of the observation to be canceled
and includes an Observe Option with the value set to '1' and includes an Observe Option with the value set to '1'
(deregister). The latter is more deterministic and thus is (de-register). The latter is more deterministic and, thus, is
RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
<t><xref target="Figure6" format="default"/> shows an example of a D
<t><xref target="Figure6"></xref> shows an example of a DOTS OTS
client requesting a DOTS server to send notifications related to a client requesting a DOTS server to send notifications related to a
mitigation request. Note that for mitigations with pre-configured mitigation request. Note that for mitigations with preconfigured
scopes (i.e., 'trigger-mitigation' set to 'false'), the state will scopes (i.e., 'trigger-mitigation' set to 'false'), the state will
need to transition from 3 (attack-stopped) to 8 need to transition from 3 (attack-stopped) to 8
(attack-mitigation-signal-loss).</t> (attack-mitigation-signal-loss).</t>
<figure anchor="Figure6">
<t><figure anchor="Figure6" <name>Notifications of Attack Mitigation Status</name>
title="Notifications of Attack Mitigation Status"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+-----------+ +-----------+ +-----------+
+-----------+ |DOTS Client| |DOTS Server|
|DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
| GET /<mid> | | GET /<mid> |
| Token: 0x4a | Registration | Token: 0x4a | Registration
| Observe: 0 | | Observe: 0 |
+----------------------------------------->| +----------------------------------------->|
| | | |
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification of | Token: 0x4a | Notification of
| Observe: 12 | the current state | Observe: 12 | the current state
| status: "attack-mitigation-in-progress" | | status: "attack-mitigation-in-progress" |
| |
|<-----------------------------------------+ |<-----------------------------------------+
| |
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 44 | a state change | Observe: 44 | a state change
| status: "attack-successfully-mitigated" | | status: "attack-successfully-mitigated" |
| |
|<-----------------------------------------+ |<-----------------------------------------+
| |
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 60 | a state change | Observe: 60 | a state change
| status: "attack-stopped" | | status: "attack-stopped" |
|<-----------------------------------------+ |<-----------------------------------------+
| | | |
... ]]></artwork> ...
</figure></t> ]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Clients Polling for Mitigation Status"> <name>DOTS Clients Polling for Mitigation Status</name>
<t>The DOTS client can send the GET request at frequent intervals <t>The DOTS client can send the GET request at frequent intervals
without the Observe Option to retrieve the configuration data of without the Observe Option to retrieve the configuration data of
the mitigation request and non-configuration data (i.e., the the mitigation request and non-configuration data (i.e., the
attack status). DOTS clients MAY be configured with a policy attack status). DOTS clients <bcp14>MAY</bcp14> be configured with a policy
indicating the frequency of polling DOTS servers to get the indicating the frequency of polling DOTS servers to get the
mitigation status. This frequency MUST NOT be more than one UDP mitigation status. This frequency <bcp14>MUST NOT</bcp14> be more th
datagram per RTT as discussed in Section 3.1.3 of <xref an one UDP
target="RFC8085"></xref>.</t> datagram per RTT as discussed in <xref target="RFC8085" section="3.1
.3" sectionFormat="of" format="default"/>.</t>
<t>If the DOTS server has been able to mitigate the attack and the <t>If the DOTS server has been able to mitigate the attack and the
attack has stopped, the DOTS server indicates as such in the attack has stopped, the DOTS server indicates as such in the
status. In such case, the DOTS client recalls the mitigation status. In such case, the DOTS client recalls the mitigation
request by issuing a DELETE request for this mitigation request request by issuing a DELETE request for this mitigation request
(<xref target="del"></xref>).</t> (<xref target="del" format="default"/>).</t>
<t>A DOTS client <bcp14>SHOULD</bcp14> react to the status of the at
<t>A DOTS client SHOULD react to the status of the attack as per tack per
the information sent by the DOTS server rather than performing its the information sent by the DOTS server rather than performing its
own detection that the attack has been mitigated. This ensures own detection that the attack has been mitigated. This ensures
that the DOTS client does not recall a mitigation request that the DOTS client does not recall a mitigation request
prematurely because it is possible that the DOTS client does not prematurely because it is possible that the DOTS client does not
sense the DDoS attack on its resources, but the DOTS server could sense the DDoS attack on its resources, but the DOTS server could
be actively mitigating the attack because the attack is not be actively mitigating the attack because the attack is not
completely averted.</t> completely averted.</t>
</section> </section>
</section> </section>
<section anchor="put" numbered="true" toc="default">
<section anchor="put" title="Efficacy Update from DOTS Clients"> <name>Efficacy Update from DOTS Clients</name>
<t>While DDoS mitigation is in progress, due to the likelihood of <t>While DDoS mitigation is in progress, due to the likelihood of
packet loss, a DOTS client MAY periodically transmit DOTS mitigation packet loss, a DOTS client <bcp14>MAY</bcp14> periodically transmit DO TS mitigation
efficacy updates to the relevant DOTS server. A PUT request is used efficacy updates to the relevant DOTS server. A PUT request is used
to convey the mitigation efficacy update to the DOTS server. This to convey the mitigation efficacy update to the DOTS server. This
PUT request is treated as a refresh of the current mitigation.</t> PUT request is treated as a refresh of the current mitigation.</t>
<t>The PUT request used for the efficacy update <bcp14>MUST</bcp14> in
<t>The PUT request used for efficacy update MUST include all the clude all the
parameters used in the PUT request to carry the DOTS mitigation parameters used in the PUT request to carry the DOTS mitigation
request (<xref target="post"></xref>) unchanged apart from the request (<xref target="post" format="default"/>) unchanged apart from the
'lifetime' parameter value. If this is not the case, the DOTS server 'lifetime' parameter value. If this is not the case, the DOTS server
MUST reject the request with a 4.00 (Bad Request).</t> <bcp14>MUST</bcp14> reject the request with a 4.00 (Bad Request).</t>
<t>The If-Match Option (<xref target="RFC7252" section="5.10.8.1" sect
<t>The If-Match Option (Section 5.10.8.1 of <xref ionFormat="of" format="default"/>) with an empty value is used to make the
target="RFC7252"></xref>) with an empty value is used to make the
PUT request conditional on the current existence of the mitigation PUT request conditional on the current existence of the mitigation
request. If UDP is used as transport, CoAP requests may arrive request. If UDP is used as transport, CoAP requests may arrive
out-of-order. For example, the DOTS client may send a PUT request to out of order. For example, the DOTS client may send a PUT request to
convey an efficacy update to the DOTS server followed by a DELETE convey an efficacy update to the DOTS server followed by a DELETE
request to withdraw the mitigation request, but the DELETE request request to withdraw the mitigation request, but the DELETE request
arrives at the DOTS server before the PUT request. To handle arrives at the DOTS server before the PUT request. To handle
out-of-order delivery of requests, if an If-Match Option is present out-of-order delivery of requests, if an If-Match Option is present
in the PUT request and the 'mid' in the request matches a mitigation in the PUT request and the 'mid' in the request matches a mitigation
request from that DOTS client, the request is processed by the DOTS request from that DOTS client, the request is processed by the DOTS
server. If no match is found, the PUT request is silently ignored by server. If no match is found, the PUT request is silently ignored by
the DOTS server.</t> the DOTS server.</t>
<t>An example of an efficacy update message, which includes an <t>An example of an efficacy update message, which includes an
If-Match Option with an empty value, is depicted in <xref If-Match Option with an empty value, is depicted in <xref target="Figu
target="Figure7"></xref>.</t> re7" format="default"/>.</t>
<figure anchor="Figure7">
<figure anchor="Figure7" title="An Example of Efficacy Update"> <name>An Example of Efficacy Update</name>
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) <sourcecode><![CDATA[
Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
If-Match: If-Match:
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
skipping to change at line 1899 skipping to change at line 1797
"lower-port": 8080 "lower-port": 8080
} }
], ],
"target-protocol": [ "target-protocol": [
6 6
], ],
"attack-status": "under-attack" "attack-status": "under-attack"
} }
] ]
} }
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t></t>
<t>The 'attack-status' parameter is a mandatory attribute when <t>The 'attack-status' parameter is a mandatory attribute when
performing an efficacy update. The various possible values contained performing an efficacy update. The various possible values contained
in the 'attack-status' parameter are described in <xref in the 'attack-status' parameter are described in <xref target="astatu
target="astatus"></xref>.</t> s" format="default"/>.</t>
<table anchor="astatus" align="center">
<texttable anchor="astatus" style="all" <name>Values of 'attack-status' Parameter</name>
title=" Values of 'attack-status' Parameter"> <thead>
<ttcol align="right">Parameter value</ttcol> <tr>
<th align="right">Parameter Value</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
</tr>
<c>1</c> </thead>
<tbody>
<c>The DOTS client determines that it is still under attack.</c> <tr>
<td align="right">1</td>
<c>2</c> <td align="left">The DOTS client determines that it is still und
er attack.</td>
<c>The DOTS client determines that the attack is successfully </tr>
mitigated (e.g., attack traffic is not seen).</c> <tr>
</texttable> <td align="right">2</td>
<td align="left">The DOTS client determines that the attack is s
uccessfully
mitigated (e.g., attack traffic is not seen).</td>
</tr>
</tbody>
</table>
<t>The DOTS server indicates the result of processing a PUT request <t>The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is using CoAP Response Codes. The Response Code 2.04 (Changed) is
returned if the DOTS server has accepted the mitigation efficacy returned if the DOTS server has accepted the mitigation efficacy
update. The error response code 5.03 (Service Unavailable) is update. The error Response Code 5.03 (Service Unavailable) is
returned if the DOTS server has erred or is incapable of performing returned if the DOTS server has erred or is incapable of performing
the mitigation. As specified in <xref target="RFC7252"></xref>, 5.03 the mitigation. As specified in <xref target="RFC7252" format="default
uses Max-Age option to indicate the number of seconds after which to "/>, 5.03
uses Max-Age Option to indicate the number of seconds after which to
retry.</t> retry.</t>
</section> </section>
<section anchor="del" numbered="true" toc="default">
<section anchor="del" title="Withdraw a Mitigation"> <name>Withdraw a Mitigation</name>
<t>DELETE requests are used to withdraw DOTS mitigation requests <t>DELETE requests are used to withdraw DOTS mitigation requests
from DOTS servers (<xref target="Figure3"></xref>).</t> from DOTS servers (<xref target="Figure3" format="default"/>).</t>
<t>'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE <t>'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE
requests.</t> requests.</t>
<t>The same considerations for manipulating 'cdid' parameter by DOTS <t>The same considerations for manipulating 'cdid' parameter by DOTS
gateways, as specified in <xref target="post"></xref>, MUST be gateways, as specified in <xref target="post" format="default"/>, <bcp 14>MUST</bcp14> be
followed for DELETE requests. Uri-Path parameters with empty values followed for DELETE requests. Uri-Path parameters with empty values
MUST NOT be present in a request.</t> <bcp14>MUST NOT</bcp14> be present in a request.</t>
<figure anchor="Figure3">
<figure anchor="Figure3" title="Withdraw a DOTS Mitigation"> <name>Withdraw a DOTS Mitigation</name>
<artwork align="left"><![CDATA[ Header: DELETE (Code=0.04) <sourcecode><![CDATA[
Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>If the DELETE request does not include 'cuid' and 'mid' <t>If the DELETE request does not include 'cuid' and 'mid'
parameters, the DOTS server MUST reply with a 4.00 (Bad parameters, the DOTS server <bcp14>MUST</bcp14> reply with a 4.00 (Bad
Request).</t> Request).</t>
<t>Once the request is validated, the DOTS server immediately <t>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
(Deleted) Response Code is returned even if the 'mid' parameter (Deleted) Response Code is returned even if the 'mid' parameter
value conveyed in the DELETE request does not exist in its value conveyed in the DELETE request does not exist in its
configuration data before the request.</t> configuration data before the request.</t>
<t>If the DOTS server finds the 'mid' parameter value conveyed in <t>If the DOTS server finds the 'mid' parameter value conveyed in
the DELETE request in its configuration data for the DOTS client, the DELETE request in its configuration data for the DOTS client,
then to protect against route or DNS flapping caused by a DOTS then to protect against route or DNS flapping caused by a DOTS
client rapidly removing a mitigation, and to dampen the effect of client rapidly removing a mitigation, and to dampen the effect of
oscillating attacks, the DOTS server MAY allow mitigation to oscillating attacks, the DOTS server <bcp14>MAY</bcp14> allow mitigati on to
continue for a limited period after acknowledging a DOTS client's continue for a limited period after acknowledging a DOTS client's
withdrawal of a mitigation request. During this period, the DOTS withdrawal of a mitigation request. During this period, the DOTS
server status messages SHOULD indicate that mitigation is active but server status messages <bcp14>SHOULD</bcp14> indicate that mitigation
terminating (<xref target="get"></xref>).</t> is active but
terminating (<xref target="get" format="default"/>).</t>
<t>The initial active-but-terminating period SHOULD be sufficiently <t>The initial active-but-terminating period <bcp14>SHOULD</bcp14> be
sufficiently
long to absorb latency incurred by route propagation. The long to absorb latency incurred by route propagation. The
active-but-terminating period SHOULD be set by default to 120 active-but-terminating period <bcp14>SHOULD</bcp14> be set by default to 120
seconds. If the client requests mitigation again before the initial seconds. If the client requests mitigation again before the initial
active-but-terminating period elapses, the DOTS server MAY active-but-terminating period elapses, the DOTS server <bcp14>MAY</bcp 14>
exponentially increase (the base of the exponent is 2) the exponentially increase (the base of the exponent is 2) the
active-but-terminating period up to a maximum of 300 seconds (5 active-but-terminating period up to a maximum of 300 seconds (5
minutes).</t> minutes).</t>
<t>Once the active-but-terminating period elapses, the DOTS server <t>Once the active-but-terminating period elapses, the DOTS server
MUST treat the mitigation as terminated, as the DOTS client is no <bcp14>MUST</bcp14> treat the mitigation as terminated, as the DOTS cl ient is no
longer responsible for the mitigation.</t> longer responsible for the mitigation.</t>
<t>If a mitigation is triggered due to a signal channel loss, the <t>If a mitigation is triggered due to a signal channel loss, the
DOTS server relies upon normal triggers to stop that mitigation DOTS server relies upon normal triggers to stop that mitigation
(typically, receipt of a valid DELETE request, expiry of the (typically, receipt of a valid DELETE request, expiry of the
mitigation lifetime, or scrubbing the traffic to the attack target). mitigation lifetime, or scrubbing the traffic to the attack target).
In particular, the DOTS server MUST NOT consider the signal channel In particular, the DOTS server <bcp14>MUST NOT</bcp14> consider the si gnal channel
recovery as a trigger to stop the mitigation.</t> recovery as a trigger to stop the mitigation.</t>
</section> </section>
</section> </section>
<section anchor="sigconfig" numbered="true" toc="default">
<section anchor="sigconfig" <name>DOTS Signal Channel Session Configuration</name>
title="DOTS Signal Channel Session Configuration">
<t>A DOTS client can negotiate, configure, and retrieve the DOTS <t>A DOTS client can negotiate, configure, and retrieve the DOTS
signal channel session behavior with its DOTS peers. The DOTS signal signal channel session behavior with its DOTS peers. The DOTS signal
channel can be used, for example, to configure the following:<list channel can be used, for example, to configure the following:</t>
style="letters"> <ol spacing="normal" type="a">
<t>Heartbeat interval (heartbeat-interval): DOTS agents regularly <li>Heartbeat interval (heartbeat-interval): DOTS agents regularly
send heartbeats to each other after mutual authentication is send heartbeats to each other after mutual authentication is
successfully completed in order to keep the DOTS signal channel successfully completed in order to keep the DOTS signal channel
open. Heartbeat messages are exchanged between DOTS agents every open. Heartbeat messages are exchanged between DOTS agents every
'heartbeat-interval' seconds to detect the current status of the 'heartbeat-interval' seconds to detect the current status of the
DOTS signal channel session.</t> DOTS signal channel session.</li>
<li>Missing heartbeats allowed (missing-hb-allowed): This variable
<t>Missing heartbeats allowed (missing-hb-allowed): This variable
indicates the maximum number of consecutive heartbeat messages for indicates the maximum number of consecutive heartbeat messages for
which a DOTS agent did not receive a response before concluding which a DOTS agent did not receive a response before concluding
that the session is disconnected or defunct.</t> that the session is disconnected or defunct.</li>
<li>Acceptable probing rate (probing-rate): This parameter
<t>Acceptable probing rate (probing-rate): This parameter
indicates the average data rate that must not be exceeded by a indicates the average data rate that must not be exceeded by a
DOTS agent in sending to a peer DOTS agent that does not DOTS agent in sending to a peer DOTS agent that does not
respond.</t> respond.</li>
<li>Acceptable signal loss ratio: Maximum retransmissions,
<t>Acceptable signal loss ratio: Maximum retransmissions,
retransmission timeout value, and other message transmission retransmission timeout value, and other message transmission
parameters for Confirmable messages over the DOTS signal parameters for Confirmable messages over the DOTS signal
channel.</t> channel.</li>
</list></t> </ol>
<t>When the DOTS signal channel is established over a reliable <t>When the DOTS signal channel is established over a reliable
transport (e.g., TCP), there is no need for the reliability mechanisms transport (e.g., TCP), there is no need for the reliability mechanisms
provided by CoAP over UDP since the underlying TCP connection provides provided by CoAP over UDP since the underlying TCP connection provides
retransmissions and deduplication <xref target="RFC8323"></xref>. As a retransmissions and deduplication <xref target="RFC8323" format="default "/>. As a
reminder, CoAP over reliable transports does not support Confirmable reminder, CoAP over reliable transports does not support Confirmable
or Non-confirmable message types. As such, the transmission-related or Non-confirmable message types. As such, the transmission-related
parameters (missing-hb-allowed and acceptable signal loss ratio) are parameters ('missing-hb-allowed' and acceptable signal loss ratio) are
negotiated only for DOTS over unreliable transports.</t> negotiated only for DOTS over unreliable transports.</t>
<t>The same or distinct configuration sets may be used during times <t>The same or distinct configuration sets may be used during times
when a mitigation is active ('mitigating-config') and when no when a mitigation is active ('mitigating-config') and when no
mitigation is active ('idle-config'). This is particularly useful for mitigation is active ('idle-config'). This is particularly useful for
DOTS servers that might want to reduce heartbeat frequency or cease DOTS servers that might want to reduce heartbeat frequency or cease
heartbeat exchanges when an active DOTS client has not requested heartbeat exchanges when an active DOTS client has not requested
mitigation. If distinct configurations are used, DOTS agents MUST mitigation. If distinct configurations are used, DOTS agents <bcp14>MUST </bcp14>
follow the appropriate configuration set as a function of the follow the appropriate configuration set as a function of the
mitigation activity (e.g., if no mitigation request is active (also mitigation activity (e.g., if no mitigation request is active (also
referred to as 'idle' time), 'idle-config'-related values must be referred to as 'idle' time), values related to 'idle-config' must be
followed). Additionally, DOTS agents MUST automatically switch to the followed). Additionally, DOTS agents <bcp14>MUST</bcp14> automatically s
witch to the
other configuration upon a change in the mitigation activity (e.g., if other configuration upon a change in the mitigation activity (e.g., if
an attack mitigation is launched after an 'idle' time, the DOTS agent an attack mitigation is launched after an 'idle' time, the DOTS agent
switches from 'idle-config' to 'mitigating-config'-related switches from values related to 'idle-config' to values
values).</t> related to 'mitigating-config').</t>
<t>CoAP requests and responses are indicated for reliable delivery by
<t>CoAP Requests and responses are indicated for reliable delivery by
marking them as Confirmable messages. DOTS signal channel session marking them as Confirmable messages. DOTS signal channel session
configuration requests and responses are marked as Confirmable configuration requests and responses are marked as Confirmable
messages. As explained in Section 2.1 of <xref messages. As explained in <xref target="RFC7252" section="2.1" sectionFo
target="RFC7252"></xref>, a Confirmable message is retransmitted using rmat="of" format="default"/>, a Confirmable message is retransmitted using
a default timeout and exponential back-off between retransmissions, a default timeout and exponential backoff between retransmissions,
until the DOTS server sends an Acknowledgement message (ACK) with the until the DOTS server sends an Acknowledgement message (ACK) with the
same Message ID conveyed from the DOTS client.</t> same Message ID conveyed from the DOTS client.</t>
<t>Message transmission parameters are defined in <xref target="RFC7252"
<t>Message transmission parameters are defined in Section 4.8 of <xref section="4.8" sectionFormat="of" format="default"/>. The DOTS server can either
target="RFC7252"></xref>. The DOTS server can either piggyback the piggyback the
response in the acknowledgement message or, if the DOTS server cannot response in the Acknowledgement message or, if the DOTS server cannot
respond immediately to a request carried in a Confirmable message, it respond immediately to a request carried in a Confirmable message, it
simply responds with an Empty Acknowledgement message so that the DOTS simply responds with an Empty Acknowledgement message so that the DOTS
client can stop retransmitting the request. Empty Acknowledgement client can stop retransmitting the request. Empty Acknowledgement
messages are explained in Section 2.2 of <xref messages are explained in <xref target="RFC7252" section="2.2" sectionFo
target="RFC7252"></xref>. When the response is ready, the server sends rmat="of" format="default"/>. When the response is ready, the server sends
it in a new Confirmable message which in turn needs to be acknowledged it in a new Confirmable message, which, in turn, needs to be acknowledge
by the DOTS client (see Sections 5.2.1 and 5.2.2 of <xref d
target="RFC7252"></xref>). Requests and responses exchanged between by the DOTS client (see Sections <xref target="RFC7252" section="5.2.1"
sectionFormat="bare" format="default"/>
and <xref target="RFC7252" section="5.2.2" sectionFormat="bare" format="default"
/>
of <xref target="RFC7252" format="default"/>). Requests and responses exchanged
between
DOTS agents during 'idle' time, except heartbeat messages, are marked DOTS agents during 'idle' time, except heartbeat messages, are marked
as Confirmable messages.<list style="empty"> as Confirmable messages.</t>
<t>Implementation Note: A DOTS client that receives a response in <aside>
<t>Implementation Note: A DOTS client that receives a response in
a Confirmable message may want to clean up the message state right a Confirmable message may want to clean up the message state right
after sending the ACK. If that ACK is lost and the DOTS server after sending the ACK. If that ACK is lost and the DOTS server
retransmits the Confirmable message, the DOTS client may no longer retransmits the Confirmable message, the DOTS client may no longer
have any state that would help it correlate this response: from have any state that would help it correlate this response: from
the DOTS client's standpoint, the retransmission message is the DOTS client's standpoint, the retransmission message is
unexpected. The DOTS client will send a Reset message so it does unexpected. The DOTS client will send a Reset message so it does
not receive any more retransmissions. This behavior is normal and not receive any more retransmissions. This behavior is normal and
not an indication of an error (see Section 5.3.2 of <xref not an indication of an error
target="RFC7252"></xref> for more details).</t> (see <xref target="RFC7252" section="5.3.2" sectionFormat="of" format="default"/
</list></t> > for more details).</t>
</aside>
<section anchor="discovery" title="Discover Configuration Parameters"> <section anchor="discovery" numbered="true" toc="default">
<name>Discover Configuration Parameters</name>
<t>A GET request is used to obtain acceptable (e.g., minimum and <t>A GET request is used to obtain acceptable (e.g., minimum and
maximum values) and current configuration parameters on the DOTS maximum values) and current configuration parameters on the DOTS
server for DOTS signal channel session configuration. This procedure server for DOTS signal channel session configuration. This procedure
occurs between a DOTS client and its immediate peer DOTS server. As occurs between a DOTS client and its immediate peer DOTS server. As
such, this GET request MUST NOT be relayed by a DOTS gateway.</t> such, this GET request <bcp14>MUST NOT</bcp14> be relayed by a DOTS ga
teway.</t>
<t><xref target="Figure18"></xref> shows how to obtain configuration <t><xref target="Figure18" format="default"/> shows how to obtain conf
iguration
parameters that the DOTS server will find acceptable.</t> parameters that the DOTS server will find acceptable.</t>
<figure anchor="Figure18">
<figure anchor="Figure18" title="GET to Retrieve Configuration"> <name>GET to Retrieve Configuration</name>
<artwork align="left"><![CDATA[ Header: GET (Code=0.01) <sourcecode><![CDATA[
Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The DOTS server in the 2.05 (Content) response conveys the <t>The DOTS server in the 2.05 (Content) response conveys the
current, minimum, and maximum attribute values acceptable by the current, minimum, and maximum attribute values acceptable by the
DOTS server (<xref target="Figure19"></xref>).</t> DOTS server (<xref target="Figure19" format="default"/>).</t>
<figure anchor="Figure19">
<t><figure anchor="Figure19" <name>GET Configuration Response Body Schema</name>
title="GET Configuration Response Body Schema"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
skipping to change at line 2178 skipping to change at line 2058
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": "string", "max-value-decimal": "string",
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
} }
} }
} }
}]]></artwork> }]]></sourcecode>
</figure></t> </figure>
<t>The parameters in <xref target="Figure19" format="default"/> are de
<t>The parameters in <xref target="Figure19"></xref> are described scribed
below:</t> below:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>mitigating-config:</dt>
<t hangText="mitigating-config:">Set of configuration parameters <dd>
<t>Set of configuration parameters
to use when a mitigation is active. The following parameters may to use when a mitigation is active. The following parameters may
be included: <list style="hanging"> be included: </t>
<t hangText="heartbeat-interval: ">Time interval in seconds <dl newline="false" spacing="normal">
between two consecutive heartbeat messages. <vspace <dt>heartbeat-interval: </dt>
blankLines="1" />'0' is used to disable the heartbeat <dd>
mechanism. <vspace blankLines="1" />This is an optional <t>Time interval in seconds
between two consecutive heartbeat messages. </t>
<t>'0' is used to disable the heartbeat
mechanism. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="missing-hb-allowed: ">Maximum number of <dt>missing-hb-allowed: </dt>
<dd>
<t>Maximum number of
consecutive heartbeat messages for which the DOTS agent did consecutive heartbeat messages for which the DOTS agent did
not receive a response before concluding that the session is not receive a response before concluding that the session is
disconnected. <vspace blankLines="1" />This is an optional disconnected. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="probing-rate:">The average data rate that must <dt>probing-rate:</dt>
<dd>
<t>The average data rate that must
not be exceeded by a DOTS agent in sending to a peer DOTS not be exceeded by a DOTS agent in sending to a peer DOTS
agent that does not respond (referred to as PROBING_RATE agent that does not respond (referred to as PROBING_RATE
parameter in CoAP). <vspace blankLines="1" />This is an parameter in CoAP). </t>
<t>This is an
optional attribute.</t> optional attribute.</t>
</dd>
<t hangText="max-retransmit: ">Maximum number of <dt>max-retransmit: </dt>
<dd>
<t>Maximum number of
retransmissions for a message (referred to as MAX_RETRANSMIT retransmissions for a message (referred to as MAX_RETRANSMIT
parameter in CoAP). <vspace blankLines="1" />This is an parameter in CoAP). </t>
<t>This is an
optional attribute.</t> optional attribute.</t>
</dd>
<t hangText="ack-timeout: ">Timeout value in seconds used to <dt>ack-timeout: </dt>
<dd>
<t>Timeout value in seconds used to
calculate the initial retransmission timeout value (referred calculate the initial retransmission timeout value (referred
to as ACK_TIMEOUT parameter in CoAP). <vspace to as ACK_TIMEOUT parameter in CoAP). </t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd>
<t hangText="ack-random-factor: ">Random factor used to <dt>ack-random-factor: </dt>
<dd>
<t>Random factor used to
influence the timing of retransmissions (referred to as influence the timing of retransmissions (referred to as
ACK_RANDOM_FACTOR parameter in CoAP). <vspace ACK_RANDOM_FACTOR parameter in CoAP). </t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</list></t> </dd>
</dl>
<t hangText="idle-config: ">Set of configuration parameters to </dd>
<dt>idle-config: </dt>
<dd>Set of configuration parameters to
use when no mitigation is active. This attribute has the same use when no mitigation is active. This attribute has the same
structure as 'mitigating-config'.</t> structure as 'mitigating-config'.</dd>
</list></t> </dl>
<t><xref target="Figure17" format="default"/> shows an example of acce
<t><xref target="Figure17"></xref> shows an example of acceptable ptable
and current configuration parameters on a DOTS server for DOTS and current configuration parameters on a DOTS server for DOTS
signal channel session configuration. The same acceptable signal channel session configuration. The same acceptable
configuration is used during mitigation and idle times.</t> configuration is used during mitigation and idle times.</t>
<figure anchor="Figure17">
<t><figure anchor="Figure17" <name>Example of a Configuration Response Body</name>
title="Example of a Configuration Response Body"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-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": 20, "max-value": 20,
"min-value": 3, "min-value": 3,
skipping to change at line 2301 skipping to change at line 2199
"min-value-decimal": "1.00", "min-value-decimal": "1.00",
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": "4.00", "max-value-decimal": "4.00",
"min-value-decimal": "1.10", "min-value-decimal": "1.10",
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
} }
} }
}]]></artwork> }]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="convey" numbered="true" toc="default">
<section anchor="convey" <name>Convey DOTS Signal Channel Session Configuration</name>
title="Convey DOTS Signal Channel Session Configuration"> <t>A PUT request (Figures <xref format="counter" target="Figure13"/>
<t>A PUT request (Figures <xref format="counter" and <xref format="counter" target="Figure13a"/>) is used to convey the
target="Figure13"></xref> and <xref format="counter" configuration
target="Figure13a"></xref>) is used to convey the configuration
parameters for the signal channel (e.g., heartbeat interval, maximum parameters for the signal channel (e.g., heartbeat interval, maximum
retransmissions). Message transmission parameters for CoAP are retransmissions). Message transmission parameters for CoAP are
defined in Section 4.8 of <xref target="RFC7252"></xref>. The defined in <xref target="RFC7252" section="4.8" sectionFormat="of" for
RECOMMENDED values of transmission parameter values are ack-timeout mat="default"/>. The
(2 seconds), max-retransmit (3), and ack-random-factor (1.5). In <bcp14>RECOMMENDED</bcp14> values of transmission parameter values are
addition to those parameters, the RECOMMENDED specific DOTS 'ack-timeout'
(2 seconds), 'max-retransmit' (3), and 'ack-random-factor' (1.5). In
addition to those parameters, the <bcp14>RECOMMENDED</bcp14> specific
DOTS
transmission parameter values are 'heartbeat-interval' (30 seconds) transmission parameter values are 'heartbeat-interval' (30 seconds)
and 'missing-hb-allowed' (15). <list style="empty"> and 'missing-hb-allowed' (15). </t>
<t>Note: heartbeat-interval should be tweaked to also assist <aside>
DOTS messages for NAT traversal (SIG-011 of <xref <t>Note: 'heartbeat-interval' should be tweaked to also assist
target="RFC8612"></xref>). According to <xref DOTS messages for NAT traversal (SIG-011 of <xref target="RFC8612"
target="RFC8085"></xref>, heartbeat messages must not be sent format="default"/>).
According to <xref target="RFC8085" format="default"/>, heartbeat
messages must not be sent
more frequently than once every 15 seconds and should use longer more frequently than once every 15 seconds and should use longer
intervals when possible. Furthermore, <xref intervals when possible. Furthermore, <xref target="RFC4787" forma
target="RFC4787"></xref> recommends NATs to use a state timeout t="default"/>
recommends that NATs use a state timeout
of 2 minutes or longer, but experience shows that sending of 2 minutes or longer, but experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the packets every 15 to 30 seconds is necessary to prevent the
majority of middleboxes from losing state for UDP flows. From majority of middleboxes from losing state for UDP flows. From
that standpoint, the RECOMMENDED minimum heartbeat-interval is that standpoint, the <bcp14>RECOMMENDED</bcp14> minimum 'heartbeat
15 seconds and the RECOMMENDED maximum heartbeat-interval is 240 -interval' is
15 seconds and the <bcp14>RECOMMENDED</bcp14> maximum 'heartbeat-i
nterval' is 240
seconds. The recommended value of 30 seconds is selected to seconds. The recommended value of 30 seconds is selected to
anticipate the expiry of NAT state.</t> anticipate the expiry of NAT state.</t>
<t>A 'heartbeat-interval' of 30 seconds may be considered
<t>A heartbeat-interval of 30 seconds may be considered as too to be too
chatty in some deployments. For such deployments, DOTS agents chatty in some deployments. For such deployments, DOTS agents
may negotiate longer heartbeat-interval values to prevent any may negotiate longer 'heartbeat-interval' values to prevent any
network overload with too frequent heartbeats.</t> network overload with too frequent heartbeats.</t>
<t>Different heartbeat intervals can be defined for
<t>Different heartbeat intervals can be defined for
'mitigating-config' and 'idle-config' to reduce being too chatty 'mitigating-config' and 'idle-config' to reduce being too chatty
during idle times. If there is an on-path translator between the during idle times. If there is an on-path translator between the
DOTS client (standalone or part of a DOTS gateway) and the DOTS DOTS client (standalone or part of a DOTS gateway) and the DOTS
server, the 'mitigating-config' heartbeat-interval has to be server, the 'mitigating-config' 'heartbeat-interval' has to be
smaller than the translator session timeout. It is recommended smaller than the translator session timeout. It is recommended
that the 'idle-config' heartbeat-interval is also smaller than that the 'idle-config' 'heartbeat-interval' also be smaller than
the translator session timeout to prevent translator traversal the translator session timeout to prevent translator traversal
issues, or disabled entirely. Means to discover the lifetime issues or that it be disabled entirely. Means to discover the life time
assigned by a translator are out of scope.</t> assigned by a translator are out of scope.</t>
<t>Given that the size of the heartbeat request cannot exceed
<t>Given that the size of the heartbeat request can not exceed ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate' shou
(heartbeat-interval * probing-rate) bytes, probing-rate should ld
be set appropriately to avoid slowing down heartbeat exchanges. be set appropriately to avoid slowing down heartbeat exchanges.
For example, probing-rate may be set to 2 * ("size of encrypted For example, 'probing-rate' may be set to 2 * ("size of encrypted
DOTS heartbeat request"/heartbeat-interval) or (("size of DOTS heartbeat request"/'heartbeat-interval') or (("size of
encrypted DOTS heartbeat request" + "average size of an encrypted DOTS heartbeat request" + "average size of an
encrypted mitigation request")/heartbeat-interval). Absent any encrypted mitigation request")/'heartbeat-interval'). Absent any
explicit configuration or inability to dynamically adjust explicit configuration or inability to dynamically adjust
probing-rate values (Section 4.8.1 of <xref 'probing-rate' values (<xref target="RFC7252" section="4.8.1" sect
target="RFC7252"></xref>), DOTS agents use 5 bytes/second as a ionFormat="of" format="default"/>),
default probing-rate value.</t> DOTS agents use 5 bytes/second as a default 'probing-rate' value.<
</list></t> /t>
</aside>
<t>If the DOTS agent wishes to change the default values of message <t>If the DOTS agent wishes to change the default values of message
transmission parameters, it SHOULD follow the guidance given in transmission parameters, it <bcp14>SHOULD</bcp14> follow the guidance
Section 4.8.1 of <xref target="RFC7252"></xref>. The DOTS agents given in
MUST use the negotiated values for message transmission parameters <xref target="RFC7252" section="4.8.1" sectionFormat="of" format="defa
ult"/>. The DOTS agents
<bcp14>MUST</bcp14> use the negotiated values for message transmission
parameters
and default values for non-negotiated message transmission and default values for non-negotiated message transmission
parameters.</t> parameters.</t>
<t>The signal channel session configuration is applicable to a <t>The signal channel session configuration is applicable to a
single DOTS signal channel session between DOTS agents, so the single DOTS signal channel session between DOTS agents, so the
'cuid' Uri-Path MUST NOT be used.</t> 'cuid' Uri-Path <bcp14>MUST NOT</bcp14> be used.</t>
<figure anchor="Figure13">
<t><figure anchor="Figure13" <name>PUT to Convey the DOTS Signal Channel Session Configuration Da
title="PUT to Convey the DOTS Signal Channel Session Configuration ta</name>
Data"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
... ...
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The additional Uri-Path parameter to those defined in <xref <t>The additional Uri-Path parameter to those defined in <xref target=
target="uris"></xref> is as follows: <list hangIndent="5" "uris" format="default"/> is as follows: </t>
style="hanging"> <dl newline="false" spacing="normal" indent="5">
<t hangText="sid:">Session Identifier is an identifier for the <dt>sid:</dt>
<dd>
<t>Session Identifier is an identifier for the
DOTS signal channel session configuration data represented as an DOTS signal channel session configuration data represented as an
integer. This identifier MUST be generated by DOTS clients. integer. This identifier <bcp14>MUST</bcp14> be generated by DOTS
'sid' values MUST increase monotonically (when a new PUT is clients.
'sid' values <bcp14>MUST</bcp14> increase monotonically (when a ne
w PUT is
generated by a DOTS client to convey the configuration generated by a DOTS client to convey the configuration
parameters for the signal channel). <vspace parameters for the signal channel). </t>
blankLines="1" />This is a mandatory attribute.</t> <t>This is a mandatory attribute.</t>
</list></t> </dd>
</dl>
<t><figure anchor="Figure13a" <figure anchor="Figure13a">
title="PUT to Convey the DOTS Signal Channel Session Configuration <name>PUT to Convey the DOTS Signal Channel Session Configuration Da
Data (Message Body Schema)"> ta (Message Body Schema)</name>
<artwork align="left"><![CDATA[ { <sourcecode><![CDATA[
{
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": number "current-value": number
}, },
"probing-rate": { "probing-rate": {
"current-value": number "current-value": number
skipping to change at line 2444 skipping to change at line 2337
"current-value": number "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "string" "current-value-decimal": "string"
} }
} }
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The meaning of the parameters in the CBOR body (<xref <t>The meaning of the parameters in the CBOR body
target="Figure13a"></xref>) is defined in <xref (<xref target="Figure13a" format="default"/>) is defined in <xref targ
target="discovery"></xref>.</t> et="discovery" format="default"/>.</t>
<t>At least one of the attributes 'heartbeat-interval', <t>At least one of the attributes 'heartbeat-interval',
'missing-hb-allowed', 'probing-rate', 'max-retransmit', 'missing-hb-allowed', 'probing-rate', 'max-retransmit',
'ack-timeout', and 'ack-random-factor' MUST be present in the PUT 'ack-timeout', and 'ack-random-factor' <bcp14>MUST</bcp14> be present in the PUT
request. Note that 'heartbeat-interval', 'missing-hb-allowed', request. Note that 'heartbeat-interval', 'missing-hb-allowed',
'probing-rate', 'max-retransmit', 'ack-timeout', and 'probing-rate', 'max-retransmit', 'ack-timeout', and
'ack-random-factor', if present, do not need to be provided for both 'ack-random-factor', if present, do not need to be provided for both
'mitigating-config', and 'idle-config' in a PUT request.</t> 'mitigating-config', and 'idle-config' in a PUT request.</t>
<t>The PUT request with a higher numeric 'sid' value overrides the <t>The PUT request with a higher numeric 'sid' value overrides the
DOTS signal channel session configuration data installed by a PUT DOTS signal channel session configuration data installed by a PUT
request with a lower numeric 'sid' value. To avoid maintaining a request with a lower numeric 'sid' value. To avoid maintaining a
long list of 'sid' requests from a DOTS client, the lower numeric long list of 'sid' requests from a DOTS client, the lower numeric
'sid' MUST be automatically deleted and no longer available at the 'sid' <bcp14>MUST</bcp14> be automatically deleted and no longer avail able at the
DOTS server.</t> DOTS server.</t>
<t><xref target="Figure14" format="default"/> shows a PUT request exam
<t><xref target="Figure14"></xref> shows a PUT request example to ple to
convey the configuration parameters for the DOTS signal channel. In convey the configuration parameters for the DOTS signal channel. In
this example, the heartbeat mechanism is disabled when no mitigation this example, the heartbeat mechanism is disabled when no mitigation
is active, while the heartbeat interval is set to '30' when a is active, while the heartbeat interval is set to '30' when a
mitigation is active.</t> mitigation is active.</t>
<figure anchor="Figure14">
<t><figure anchor="Figure14" <name>PUT to Convey the Configuration Parameters</name>
title="PUT to Convey the Configuration Parameters"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
skipping to change at line 2518 skipping to change at line 2407
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
} }
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The DOTS server indicates the result of processing the PUT <t>The DOTS server indicates the result of processing the PUT
request using CoAP response codes:<list style="symbols"> request using CoAP Response Codes:</t>
<t>If the request is missing a mandatory attribute, does not <ul spacing="normal">
<li>If the request is missing a mandatory attribute, does not
include a 'sid' Uri-Path, or contains one or more invalid or include a 'sid' Uri-Path, or contains one or more invalid or
unknown parameters, 4.00 (Bad Request) MUST be returned in the unknown parameters, 4.00 (Bad Request) <bcp14>MUST</bcp14> be retu
response.</t> rned in the
response.</li>
<t>If the DOTS server does not find the 'sid' parameter value <li>If the DOTS server does not find the 'sid' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a DOTS server has accepted the configuration parameters, then a
response code 2.01 (Created) MUST be returned in the Response Code 2.01 (Created) <bcp14>MUST</bcp14> be returned in th
response.</t> e
response.</li>
<t>If the DOTS server finds the 'sid' parameter value conveyed <li>If the DOTS server finds the 'sid' parameter value conveyed
in the PUT request in its configuration data and if the DOTS in the PUT request in its configuration data and if the DOTS
server has accepted the updated configuration parameters, 2.04 server has accepted the updated configuration parameters, 2.04
(Changed) MUST be returned in the response.</t> (Changed) <bcp14>MUST</bcp14> be returned in the response.</li>
<li>
<t>If any of the 'heartbeat-interval', 'missing-hb-allowed', <t>If any of the 'heartbeat-interval', 'missing-hb-allowed',
'probing-rate', 'max-retransmit', 'target-protocol', 'probing-rate', 'max-retransmit', 'target-protocol',
'ack-timeout', and 'ack-random-factor' attribute values are not 'ack-timeout', and 'ack-random-factor' attribute values are not
acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST acceptable to the DOTS server, 4.22 (Unprocessable Entity) <bcp14> MUST</bcp14>
be returned in the response. Upon receipt of this error code, be returned in the response. Upon receipt of this error code,
the DOTS client SHOULD retrieve the maximum and minimum the DOTS client <bcp14>SHOULD</bcp14> retrieve the maximum and min
attribute values acceptable to the DOTS server (<xref imum
target="discovery"></xref>).<vspace blankLines="1" />The DOTS attribute values acceptable to the DOTS server (<xref target="disc
client may re-try and send the PUT request with updated overy" format="default"/>).</t>
<t>The DOTS
client may retry and send the PUT request with updated
attribute values acceptable to the DOTS server.</t> attribute values acceptable to the DOTS server.</t>
</list></t> </li>
</ul>
<t>A DOTS client may issue a GET message with 'sid' Uri-Path <t>A DOTS client may issue a GET message with a 'sid' Uri-Path
parameter to retrieve the negotiated configuration. The response parameter to retrieve the negotiated configuration. The response
does not need to include 'sid' in its message body.</t> does not need to include 'sid' in its message body.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Configuration Freshness and Notifications"> <name>Configuration Freshness and Notifications</name>
<t>Max-Age Option (Section 5.10.5 of <xref target="RFC7252"></xref>) <t>Max-Age Option (<xref target="RFC7252" section="5.10.5" sectionForm
SHOULD be returned by a DOTS server to associate a validity time at="of" format="default"/>)
<bcp14>SHOULD</bcp14> be returned by a DOTS server to associate a vali
dity time
with a configuration it sends. This feature allows the update of the with a configuration it sends. This feature allows the update of the
configuration data if a change occurs at the DOTS server side. For configuration data if a change occurs at the DOTS server side. For
example, the new configuration may instruct a DOTS client to cease example, the new configuration may instruct a DOTS client to cease
heartbeats or reduce heartbeat frequency.</t> heartbeats or reduce heartbeat frequency.</t>
<t>It is <bcp14>NOT RECOMMENDED</bcp14> to return a Max-Age Option set
<t>It is NOT RECOMMENDED to return a Max-Age Option set to 0.</t> to 0.</t>
<t>Returning a Max-Age Option set to 2<sup>32</sup>-1 is equivalent to
<t>Returning a Max-Age Option set to 2**32-1 is equivalent to
associating an infinite lifetime with the configuration.</t> associating an infinite lifetime with the configuration.</t>
<t>If a non-zero value of Max-Age Option is received by a DOTS <t>If a non-zero value of Max-Age Option is received by a DOTS
client, it MUST issue a GET request with 'sid' Uri-Path parameter to client, it <bcp14>MUST</bcp14> issue a GET request with a 'sid' Uri-Pa th parameter to
retrieve the current and acceptable configuration before the expiry retrieve the current and acceptable configuration before the expiry
of the value enclosed in the Max-Age option. This request is of the value enclosed in the Max-Age Option. This request is
considered by the client and the server as a means to refresh the considered by the client and the server to be a means to refresh the
configuration parameters for the signal channel. When a DDoS attack configuration parameters for the signal channel. When a DDoS attack
is active, refresh requests MUST NOT be sent by DOTS clients and the is active, refresh requests <bcp14>MUST NOT</bcp14> be sent by DOTS cl
DOTS server MUST NOT terminate the (D)TLS session after the expiry ients, and the
DOTS server <bcp14>MUST NOT</bcp14> terminate the (D)TLS session after
the expiry
of the value returned in Max-Age Option.</t> of the value returned in Max-Age Option.</t>
<t>If Max-Age Option is not returned in a response, the DOTS client <t>If Max-Age Option is not returned in a response, the DOTS client
initiates GET requests to refresh the configuration parameters each initiates GET requests to refresh the configuration parameters each
60 seconds (Section 5.10.5 of <xref target="RFC7252"></xref>). To 60 seconds (<xref target="RFC7252" section="5.10.5" sectionFormat="of"
prevent such overload, it is RECOMMENDED that DOTS servers return a format="default"/>). To
prevent such overload, it is <bcp14>RECOMMENDED</bcp14> that DOTS serv
ers return a
Max-Age Option in GET responses. Considerations related to which Max-Age Option in GET responses. Considerations related to which
value to use and how such value is set, are implementation- and value to use and how such a value is set are implementation and
deployment-specific.</t> deployment specific.</t>
<t>If an Observe Option set to 0 is included in the configuration <t>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 <xref target="RFC7641"></xref>).</t> change (<xref target="RFC7641" section="4.2" sectionFormat="of" format
="default"/>).</t>
<t>If a DOTS server detects that a misbehaving DOTS client does not <t>If a DOTS server detects that a misbehaving DOTS client does not
contact the DOTS server after the expiry of Max-Age and retrieve the contact the DOTS server after the expiry of Max-Age to retrieve the
signal channel configuration data, it MAY terminate the (D)TLS signal channel configuration data, it <bcp14>MAY</bcp14> terminate the
(D)TLS
session. A (D)TLS session is terminated by the receipt of an session. A (D)TLS session is terminated by the receipt of an
authenticated message that closes the connection (e.g., a fatal authenticated message that closes the connection (e.g., a fatal
alert (Section 6 of <xref target="RFC8446"></xref>)).</t> alert (<xref target="RFC8446" section="6" sectionFormat="of" format="d efault"/>)).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Delete DOTS Signal Channel Session Configuration"> <name>Delete DOTS Signal Channel Session Configuration</name>
<t>A DELETE request is used to delete the installed DOTS signal <t>A DELETE request is used to delete the installed DOTS signal
channel session configuration data (<xref channel session configuration data (<xref target="Figure15" format="de
target="Figure15"></xref>).</t> fault"/>).</t>
<figure anchor="Figure15">
<figure anchor="Figure15" title="Delete Configuration"> <name>Delete Configuration</name>
<artwork align="left"><![CDATA[ Header: DELETE (Code=0.04) <sourcecode><![CDATA[
Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The DOTS server resets the DOTS signal channel session <t>The DOTS server resets the DOTS signal channel session
configuration back to the default values and acknowledges a DOTS configuration back to the default values and acknowledges a DOTS
client's request to remove the DOTS signal channel session client's request to remove the DOTS signal channel session
configuration using 2.02 (Deleted) response code.</t> configuration using 2.02 (Deleted) Response Code.</t>
<t>Upon bootstrapping or reboot, a DOTS client <bcp14>MAY</bcp14> send
<t>Upon bootstrapping or reboot, a DOTS client MAY send a DELETE a DELETE
request to set the configuration parameters to default values. Such request to set the configuration parameters to default values. Such
a request does not include any 'sid'.</t> a request does not include any 'sid'.</t>
</section> </section>
</section> </section>
<section anchor="redirect" numbered="true" toc="default">
<section anchor="redirect" title="Redirected Signaling"> <name>Redirected Signaling</name>
<t>Redirected DOTS signaling is discussed in detail in Section 3.2.2 <t>Redirected DOTS signaling is discussed in detail in
of <xref target="I-D.ietf-dots-architecture"></xref>.</t> <xref target="I-D.ietf-dots-architecture" section="3.2.2" sectionFormat=
"of" format="default"/>.</t>
<t>If a DOTS server wants to redirect a DOTS client to an alternative <t>If a DOTS server wants to redirect a DOTS client to an alternative
DOTS server for a signal session, then the response code 5.03 (Service DOTS server for a signal session, then the Response Code 5.03 (Service
Unavailable) will be returned in the response to the DOTS client.</t> Unavailable) will be returned in the response to the DOTS client.</t>
<t>The DOTS server can return the error Response Code 5.03 in response
<t>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
5.03 in a unidirectional notification response from the DOTS 5.03 in a unidirectional notification response from the DOTS
server.</t> server.</t>
<t>The DOTS server in the error response conveys the alternate DOTS <t>The DOTS server in the error response conveys the alternate DOTS
server's FQDN, and the alternate DOTS server's IP address(es) values server's FQDN, and the alternate DOTS server's IP address(es) values
in the CBOR body (<xref target="Figure20"></xref>).</t> in the CBOR body (<xref target="Figure20" format="default"/>).</t>
<figure anchor="Figure20">
<figure anchor="Figure20" <name>Redirected Server Error Response Body Schema</name>
title="Redirected Server Error Response Body Schema"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[{ {
"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"
] ]
}]]></artwork> }
}]]></sourcecode>
</figure> </figure>
<t>The parameters are described below:</t> <t>The parameters are described below:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>alt-server:</dt>
<t hangText="alt-server:">FQDN of an alternate DOTS server. <dd>
<vspace blankLines="1" />This is a mandatory attribute.</t> <t>FQDN of an alternate DOTS server.
</t>
<t hangText="alt-server-record:">A list of IP addresses of an <t>This is a mandatory attribute.</t>
alternate DOTS server.<vspace blankLines="1" />This is an optional </dd>
<dt>alt-server-record:</dt>
<dd>
<t>A list of IP addresses of an
alternate DOTS server.</t>
<t>This is an optional
attribute.</t> attribute.</t>
</list></t> </dd>
</dl>
<t>The DOTS server returns the Time to live (TTL) of the alternate <t>The DOTS server returns the Time to Live (TTL) of the alternate
DOTS server in a Max-Age Option. That is, the time interval that the DOTS server in a Max-Age Option. That is, the time interval that the
alternate DOTS server may be cached for use by a DOTS client. A alternate DOTS server may be cached for use by a DOTS client. A
Max-Age Option set to 2**32-1 is equivalent to receiving an infinite Max-Age Option set to 2<sup>32</sup>-1 is equivalent to receiving an inf inite
TTL. This value means that the alternate DOTS server is to be used TTL. This value means that the alternate DOTS server is to be used
until the alternate DOTS server redirects the traffic with another until the alternate DOTS server redirects the traffic with another
5.03 response which encloses an alternate server.</t> 5.03 response that conveys an alternate server's FQDN.</t>
<t>A Max-Age Option set to '0' may be returned for redirecting <t>A Max-Age Option set to '0' may be returned for redirecting
mitigation requests. Such value means that the redirection applies mitigation requests. Such a value means that the redirection applies
only for the mitigation request in progress. Returning short TTL in a only for the mitigation request in progress. Returning short TTL in a
Max-Age Option may adversely impact DOTS clients on slow links. Max-Age Option may adversely impact DOTS clients on slow links.
Returning short values should be avoided under such conditions.</t> Returning short values should be avoided under such conditions.</t>
<t>If the alternate DOTS server TTL has expired, the DOTS client <bcp14>
<t>If the alternate DOTS server TTL has expired, the DOTS client MUST MUST</bcp14>
use the DOTS server(s), that was provisioned using means discussed in use the DOTS server(s) that was provisioned using means discussed in
<xref target="discover"></xref>. This fall back mechanism is triggered <xref target="discover" format="default"/>. This fallback mechanism is t
riggered
immediately upon expiry of the TTL, except when a DDoS attack is immediately upon expiry of the TTL, except when a DDoS attack is
active.</t> active.</t>
<t>Requests issued by misbehaving DOTS clients that do not honor the
<t>Requests issued by misbehaving DOTS clients which do not honor the TTL conveyed in the Max-Age Option or react to explicit redirect
TTL conveyed in the Max-Age Option or react to explicit re-direct
messages can be rejected by DOTS servers.</t> messages can be rejected by DOTS servers.</t>
<t><xref target="Figure21" format="default"/> shows a 5.03 response exam
<t><xref target="Figure21"></xref> shows a 5.03 response example to ple to
convey the DOTS alternate server 'alt-server.example' together with convey the DOTS alternate server 'alt-server.example' together with
its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2.</t> its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2.</t>
<figure anchor="Figure21">
<t><figure anchor="Figure21" <name>Example of Redirected Server Error Response Body</name>
title="Example of Redirected Server Error Response Body"> <sourcecode><![CDATA[
<artwork align="left"><![CDATA[{ {
"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"
] ]
}]]></artwork> }
</figure></t> }]]></sourcecode>
</figure>
<t>When the DOTS client receives 5.03 response with an alternate <t>When the DOTS client receives a 5.03 response with an alternate
server included, it considers the current request as failed, but server included, it considers the current request to have
SHOULD try re-sending the request to the alternate DOTS server. During failed, but it
<bcp14>SHOULD</bcp14> try resending the request to the alternate DOTS se
rver. During
a DDoS attack, the DNS server may be the target of another DDoS a DDoS attack, the DNS server may be the target of another DDoS
attack, alternate DOTS server's IP addresses conveyed in the 5.03 attack, the alternate DOTS server's IP addresses conveyed in the 5.03
response help the DOTS client skip DNS lookup of the alternate DOTS response help the DOTS client skip the DNS lookup of the alternate DOTS
server, at the cost of trusting the first DOTS server to provide server, at the cost of trusting the first DOTS server to provide
accurate information. The DOTS client can then try to establish a UDP accurate information. The DOTS client can then try to establish a UDP
or a TCP session with the alternate DOTS server. The DOTS client MAY or a TCP session with the alternate DOTS server. The DOTS client <bcp14>
implement a method to construct IPv4-embedded IPv6 addresses <xref MAY</bcp14>
target="RFC6052"></xref>; this is required to handle the scenario implement a method to construct IPv4-embedded IPv6 addresses <xref targe
t="RFC6052" format="default"/>; this is required to handle the scenario
where an IPv6-only DOTS client communicates with an IPv4-only where an IPv6-only DOTS client communicates with an IPv4-only
alternate DOTS server.</t> alternate DOTS server.</t>
<t>If the DOTS client has been redirected to a DOTS server with which it
<t>If the DOTS client has been redirected to a DOTS server to which it has already communicated within the last five (5) minutes, it
has already communicated with within the last five (5) minutes, it <bcp14>MUST</bcp14> ignore the redirection and try to contact other DOTS
MUST ignore the redirection and try to contact other DOTS servers 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 <xref such as DHCP or SRV procedures <xref target="I-D.ietf-dots-server-discov
target="I-D.ietf-dots-server-discovery"></xref>. It is RECOMMENDED ery" format="default"/>. It is <bcp14>RECOMMENDED</bcp14>
that DOTS clients support means to alert administrators about redirect that DOTS clients support the means to alert administrators about redire
ct
loops.</t> loops.</t>
</section> </section>
<section anchor="hb" numbered="true" toc="default">
<section anchor="hb" title="Heartbeat Mechanism"> <name>Heartbeat Mechanism</name>
<t>To provide an indication of signal health and distinguish an 'idle' <t>To provide an indication of signal health and to distinguish an 'idle
'
signal channel from a 'disconnected' or 'defunct' session, the DOTS signal channel from a 'disconnected' or 'defunct' session, the DOTS
agent sends a heartbeat over the signal channel to maintain its half agent sends a heartbeat over the signal channel to maintain its half
of the channel (also, aligned with the "consents" recommendation in of the channel (also, aligned with the "consents" recommendation in
Section 6 of <xref target="RFC8085"></xref>). The DOTS agent similarly <xref target="RFC8085" section="6" sectionFormat="of" format="default"/>
expects a heartbeat from its peer DOTS agent, and may consider a ). The DOTS agent similarly
expects a heartbeat from its peer DOTS agent, and it may consider a
session terminated in the prolonged absence of a peer agent heartbeat. session terminated in the prolonged absence of a peer agent heartbeat.
Concretely, while the communication between the DOTS agents is Concretely, while the communication between the DOTS agents is
otherwise quiescent, the DOTS client will probe the DOTS server to otherwise quiescent, the DOTS client will probe the DOTS server to
ensure it has maintained cryptographic state and vice versa. Such ensure it has maintained cryptographic state and vice versa.
probes can also keep firewalls and/or stateful translators bindings Such probes can also keep the bindings of firewalls and/or stateful translators
alive. This probing reduces the frequency of establishing a new alive.
This probing reduces the frequency of establishing a new
handshake when a DOTS signal needs to be conveyed to the DOTS handshake when a DOTS signal needs to be conveyed to the DOTS
server.<list style="empty"> server.</t>
<t>Implementation Note: Given that CoAP roles can be multiplexed <aside>
over the same session as discussed in <xref <t>Implementation Note: Given that CoAP roles can be multiplexed
target="RFC7252"></xref> and already supported by CoAP over the same session as discussed in <xref target="RFC7252" format=
"default"/>
and are already supported by CoAP
implementations, both the DOTS client and server can send DOTS implementations, both the DOTS client and server can send DOTS
heartbeat requests.</t> heartbeat requests.</t>
</list></t> </aside>
<t>The DOTS heartbeat mechanism uses Non-confirmable PUT requests
<t>The DOTS Heartbeat mechanism uses non-confirmable PUT requests (<xref target="hbreq" format="default"/>) with an expected 2.04 (Changed
(<xref target="hbreq"></xref>) with an expected 2.04 (Changed) )
Response Code (<xref target="hbrep"></xref>). This procedure occurs Response Code (<xref target="hbrep" format="default"/>). This procedure
occurs
between a DOTS agent and its immediate peer DOTS agent. As such, this between a DOTS agent and its immediate peer DOTS agent. As such, this
PUT request MUST NOT be relayed by a DOTS gateway. The PUT request PUT request <bcp14>MUST NOT</bcp14> be relayed by a DOTS gateway. The PU
used for DOTS heartbeat MUST NOT have a 'cuid', 'cdid,' or 'mid' T request
used for DOTS heartbeat <bcp14>MUST NOT</bcp14> have a 'cuid', 'cdid', o
r 'mid'
Uri-Path.</t> Uri-Path.</t>
<figure anchor="hbreq">
<t><figure anchor="hbreq" <name>PUT to Check Peer DOTS Agent Is Responding</name>
title="PUT to Check Peer DOTS Agent is Responding"> <sourcecode><![CDATA[
<artwork><![CDATA[ Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "hb" Uri-Path: "hb"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:heartbeat": { "ietf-dots-signal-channel:heartbeat": {
"peer-hb-status": true "peer-hb-status": true
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The mandatory 'peer-hb-status' attribute is set to 'true' (or <t>The mandatory 'peer-hb-status' attribute is set to 'true' (or
'false') to indicates that a DOTS agent is (or not) receiving 'false') to indicate that a DOTS agent is (or is not) receiving
heartbeat messages from its peer in the last (2 * heartbeat-interval) heartbeat messages from its peer in the last (2 * 'heartbeat-interval')
period. Such information can be used by a peer DOTS agent to detect or period. Such information can be used by a peer DOTS agent to detect or
confirm connectivity issues and react accordingly. For example, if a confirm connectivity issues and react accordingly. For example, if a
DOTS client receives 2.04 response for its heartbeat messages but no DOTS client receives a 2.04 response for its heartbeat messages but no
server-initiated heartbeat messages, the DOTS client sets server-initiated heartbeat messages, the DOTS client sets
'peer-hb-status' to 'false'. The DOTS server will need then to try 'peer-hb-status' to 'false'. The DOTS server then will need to try
another strategy for sending the heartbeats (e.g., adjust the another strategy for sending the heartbeats (e.g., adjust the
heartbeat interval or send a server-initiated heartbeat immediately heartbeat interval or send a server-initiated heartbeat immediately
after receiving a client-initiated heartbeat message).</t> after receiving a client-initiated heartbeat message).</t>
<figure anchor="hbrep">
<name>Response to a DOTS Heartbeat Request</name>
<sourcecode><![CDATA[
Header: (Code=2.04)
<t><figure anchor="hbrep" title="Response to a DOTS Heartbeat Request"> ]]></sourcecode>
<artwork><![CDATA[ Header: (Code=2.04) </figure>
<t>DOTS servers <bcp14>MAY</bcp14> trigger their heartbeat requests imme
]]></artwork> diately after
</figure></t>
<t>DOTS servers MAY trigger their heartbeat requests immediately after
receiving heartbeat probes from peer DOTS clients. As a reminder, it receiving heartbeat probes from peer DOTS clients. As a reminder, it
is the responsibility of DOTS clients to ensure that on-path is the responsibility of DOTS clients to ensure that on-path
translators/firewalls are maintaining a binding so that the same translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS signal external IP address and/or port number is retained for the DOTS signal
channel session.</t> channel session.</t>
<t>Under normal traffic conditions (i.e., no attack is ongoing), if a <t>Under normal traffic conditions (i.e., no attack is ongoing), if a
DOTS agent does not receive any response from the peer DOTS agent for DOTS agent does not receive any response from the peer DOTS agent for
'missing-hb-allowed' number of consecutive heartbeat messages, it 'missing-hb-allowed' number of consecutive heartbeat messages, it
concludes that the DOTS signal channel session is disconnected. The concludes that the DOTS signal channel session is disconnected. The
DOTS client MUST then try to re-establish the DOTS signal channel DOTS client <bcp14>MUST</bcp14> then try to reestablish the DOTS signal
session, preferably by resuming the (D)TLS session.<list style="empty"> channel
<t hangText="Note 4:">Note: If a new DOTS signal channel session session, preferably by resuming the (D)TLS session.</t>
cannot be established, the DOTS client SHOULD NOT retry to <aside>
<t>Note: If a new DOTS signal channel session
cannot be established, the DOTS client <bcp14>SHOULD NOT</bcp14> ret
ry to
establish the DOTS signal channel session more frequently than establish the DOTS signal channel session more frequently than
every 300 seconds (5 minutes) and MUST NOT retry more frequently every 300 seconds (5 minutes) and <bcp14>MUST NOT</bcp14> retry more frequently
than every 60 seconds (1 minute). It is recommended that DOTS than every 60 seconds (1 minute). It is recommended that DOTS
clients support means to alert administrators about the failure to clients support the means to alert administrators about the failure to
establish a (D)TLS session.</t> establish a (D)TLS session.</t>
</list></t> </aside>
<t>In case of a massive DDoS attack that saturates the incoming <t>In case of a massive DDoS attack that saturates the incoming
link(s) to the DOTS client, all traffic from the DOTS server to the link(s) to the DOTS client, all traffic from the DOTS server to the
DOTS client will likely be dropped, although the DOTS server receives DOTS client will likely be dropped, although the DOTS server receives
heartbeat requests in addition to DOTS messages sent by the DOTS heartbeat requests in addition to DOTS messages sent by the DOTS
client. In this scenario, DOTS clients MUST behave differently to client. In this scenario, DOTS clients <bcp14>MUST</bcp14> behave differ ently to
handle message transmission and DOTS signal channel session liveliness handle message transmission and DOTS signal channel session liveliness
during link saturation:</t> during link saturation:</t>
<ul empty="true" spacing="normal">
<t><list style="empty"> <li>
<t>The DOTS client MUST NOT consider the DOTS signal channel <t>The DOTS client <bcp14>MUST NOT</bcp14> consider the DOTS signal
channel
session terminated even after a maximum 'missing-hb-allowed' session terminated even after a maximum 'missing-hb-allowed'
threshold is reached. The DOTS client SHOULD keep on using the threshold is reached. The DOTS client <bcp14>SHOULD</bcp14> keep on using the
current DOTS signal channel session to send heartbeat requests current DOTS signal channel session to send heartbeat requests
over it, so that the DOTS server knows the DOTS client has not over it, so that the DOTS server knows the DOTS client has not
disconnected the DOTS signal channel session. <vspace disconnected the DOTS signal channel session. </t>
blankLines="1" />After the maximum 'missing-hb-allowed' threshold <t>After the maximum 'missing-hb-allowed' threshold
is reached, the DOTS client SHOULD try to establish a new DOTS is reached, the DOTS client <bcp14>SHOULD</bcp14> try to establish a
signal channel session. The DOTS client SHOULD send mitigation new DOTS
signal channel session. The DOTS client <bcp14>SHOULD</bcp14> send m
itigation
requests over the current DOTS signal channel session and, in requests over the current DOTS signal channel session and, in
parallel, send the mitigation requests over the new DOTS signal parallel, send the mitigation requests over the new DOTS signal
channel session. This may be handled, for example, by resumption channel session. This may be handled, for example, by resumption
of the (D)TLS session or using 0-RTT mode in DTLS 1.3 to piggyback of the (D)TLS session or using 0-RTT mode in DTLS 1.3 to piggyback
the mitigation request in the ClientHello message.</t> the mitigation request in the ClientHello message.</t>
<t>As soon as the link is no longer
<t><vspace blankLines="1" />As soon as the link is no longer
saturated, if traffic from the DOTS server reaches the DOTS client saturated, if traffic from the DOTS server reaches the DOTS client
over the current DOTS signal channel session, the DOTS client can over the current DOTS signal channel session, the DOTS client can
stop the new DOTS signal channel session attempt or if a new DOTS stop the new DOTS signal channel session attempt or if a new DOTS
signal channel session is successful then disconnect the current signal channel session is successful then disconnect the current
DOTS signal channel session.</t> DOTS signal channel session.</t>
</list></t> </li>
</ul>
<t>If the DOTS server receives traffic from the peer DOTS client <t>If the DOTS server receives traffic from the peer DOTS client
(e.g., peer DOTS client initiated heartbeats) but maximum (e.g., peer DOTS client-initiated heartbeats) but the maximum
'missing-hb-allowed' threshold is reached, the DOTS server MUST NOT 'missing-hb-allowed' threshold is reached, the DOTS server <bcp14>MUST N
OT</bcp14>
consider the DOTS signal channel session disconnected. The DOTS server consider the DOTS signal channel session disconnected. The DOTS server
MUST keep on using the current DOTS signal channel session so that the <bcp14>MUST</bcp14> keep on using the current DOTS signal channel sessio n so that the
DOTS client can send mitigation requests over the current DOTS signal DOTS client can send mitigation requests over the current DOTS signal
channel session. In this case, the DOTS server can identify the DOTS channel session. In this case, the DOTS server can identify that the DOT
client is under attack and the inbound link to the DOTS client S
client is under attack and that the inbound link to the DOTS client
(domain) is saturated. Furthermore, if the DOTS server does not (domain) is saturated. Furthermore, if the DOTS server does not
receive a mitigation request from the DOTS client, it implies the DOTS receive a mitigation request from the DOTS client, it implies that the D OTS
client has not detected the attack or, if an attack mitigation is in client has not detected the attack or, if an attack mitigation is in
progress, it implies the applied DDoS mitigation actions are not yet progress, it implies that the applied DDoS mitigation actions are not ye
effective to handle the DDoS attack volume.</t> t
effectively handling the DDoS attack volume.</t>
<t>If the DOTS server does not receive any traffic from the peer DOTS <t>If the DOTS server does not receive any traffic from the peer DOTS
client during the time span required to exhaust the maximum client during the time span required to exhaust the maximum
'missing-hb-allowed' threshold, the DOTS server concludes the session 'missing-hb-allowed' threshold, the DOTS server concludes the session
is disconnected. The DOTS server can then trigger pre-configured is disconnected. The DOTS server can then trigger preconfigured
mitigation requests for this DOTS client (if any).</t> mitigation requests for this DOTS client (if any).</t>
<t>In DOTS over TCP, the sender of a DOTS heartbeat message has to <t>In DOTS over TCP, the sender of a DOTS heartbeat message has to
allow up to 'heartbeat-interval' seconds when waiting for a heartbeat allow up to 'heartbeat-interval' seconds when waiting for a heartbeat
reply. When a failure is detected by a DOTS client, it proceeds with reply. When a failure is detected by a DOTS client, it proceeds with
the session recovery following the same approach as the one used for the session recovery, following the same approach as the one used for
unreliable transports.</t> unreliable transports.</t>
</section> </section>
</section> </section>
<section anchor="YANG" numbered="true" toc="default">
<section anchor="YANG" title="DOTS Signal Channel YANG Modules"> <name>DOTS Signal Channel YANG Modules</name>
<t>This document defines a YANG <xref target="RFC7950"></xref> module <t>This document defines a YANG module <xref target="RFC7950" format="defa
ult"/>
for DOTS mitigation scope, DOTS signal channel session configuration for DOTS mitigation scope, DOTS signal channel session configuration
data, DOTS redirection signaling, and DOTS heartbeats.</t> data, DOTS redirection signaling, and DOTS heartbeats.</t>
<t>This YANG module (ietf-dots-signal-channel) defines the DOTS client <t>This YANG module (ietf-dots-signal-channel) defines the DOTS client
interaction with the DOTS server as seen by the DOTS client. A DOTS interaction with the DOTS server as seen by the DOTS client. A DOTS
server is allowed to update the non-configurable 'ro' entities in the server is allowed to update the non-configurable 'ro' entities in the
responses. This YANG module is not intended to be used via responses. This YANG module is not intended to be used via
NETCONF/RESTCONF for DOTS server management purposes; such module is out NETCONF/RESTCONF for DOTS server management purposes; such a module is out
of the scope of this document. It serves only to provide a data model of the scope of this document. It serves only to provide a data model
and encoding, but not a management data model.</t> and encoding, but not a management data model.</t>
<t>A companion YANG module is defined to include a collection of types <t>A companion YANG module is defined to include a collection of types
defined by IANA: "iana-dots-signal-channel" (<xref defined by IANA: "iana-dots-signal-channel" (<xref target="iana-yang" form
target="iana-yang"></xref>).</t> at="default"/>).</t>
<section numbered="true" toc="default">
<section title="Tree Structure"> <name>Tree Structure</name>
<t>This document defines the YANG module "ietf-dots-signal-channel" <t>This document defines the YANG module "ietf-dots-signal-channel"
(<xref target="yrequest"></xref>), which has the following tree (<xref target="yrequest" format="default"/>), which has the following tr ee
structure. A DOTS signal message can be a mitigation, a configuration, structure. A DOTS signal message can be a mitigation, a configuration,
a redirect, or a heartbeat message.</t> a redirect, or a heartbeat message.</t>
<sourcecode type="yangtree"><![CDATA[
<t><figure> module: ietf-dots-signal-channel
<artwork><![CDATA[module: ietf-dots-signal-channel +--rw dots-signal
+--rw dots-signal +--rw (message-type)?
+--rw (message-type)? +--:(mitigation-scope)
+--:(mitigation-scope) | +--rw scope* [cuid mid]
| +--rw scope* [cuid mid] | +--rw cdid? string
| +--rw cdid? string | +--rw cuid string
| +--rw cuid string | +--rw mid uint32
| +--rw mid uint32 | +--rw target-prefix* inet:ip-prefix
| +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port]
| +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number
| | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number
| | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8
| +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name
| +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri
| +--rw target-uri* inet:uri | +--rw alias-name* string
| +--rw alias-name* string | +--rw lifetime? int32
| +--rw lifetime? int32 | +--rw trigger-mitigation? boolean
| +--rw trigger-mitigation? boolean | +--ro mitigation-start? uint64
| +--ro mitigation-start? uint64 | +--ro status? iana-signal:status
| +--ro status? iana-signal:status | +--ro conflict-information
| +--ro conflict-information | | +--ro conflict-status? iana-signal:conflict-status
| | +--ro conflict-status? iana-signal:conflict-status | | +--ro conflict-cause? iana-signal:conflict-cause
| | +--ro conflict-cause? iana-signal:conflict-cause | | +--ro retry-timer? uint32
| | +--ro retry-timer? uint32 | | +--ro conflict-scope
| | +--ro conflict-scope | | +--ro target-prefix* inet:ip-prefix
| | +--ro target-prefix* inet:ip-prefix | | +--ro target-port-range* [lower-port]
| | +--ro target-port-range* [lower-port] | | | +--ro lower-port inet:port-number
| | | +--ro lower-port inet:port-number | | | +--ro upper-port? inet:port-number
| | | +--ro upper-port? inet:port-number | | +--ro target-protocol* uint8
| | +--ro target-protocol* uint8 | | +--ro target-fqdn* inet:domain-name
| | +--ro target-fqdn* inet:domain-name | | +--ro target-uri* inet:uri
| | +--ro target-uri* inet:uri | | +--ro alias-name* string
| | +--ro alias-name* string | | +--ro acl-list* [acl-name]
| | +--ro acl-list* [acl-name] | | | +--ro acl-name
| | | +--ro acl-name | | | | -> /ietf-data:dots-data/dots-client/acls/
| | | | -> /ietf-data:dots-data/dots-client/acls/ | | | | acl/name
| | | | acl/name | | | +--ro acl-type?
| | | +--ro acl-type? | | | -> /ietf-data:dots-data/dots-client/acls/
| | | -> /ietf-data:dots-data/dots-client/acls/ | | | acl/type
| | | acl/type | | +--ro mid? -> ../../../mid
| | +--ro mid? -> ../../../mid | +--ro bytes-dropped? yang:zero-based-counter64
| +--ro bytes-dropped? yang:zero-based-counter64 | +--ro bps-dropped? yang:gauge64
| +--ro bps-dropped? yang:gauge64 | +--ro pkts-dropped? yang:zero-based-counter64
| +--ro pkts-dropped? yang:zero-based-counter64 | +--ro pps-dropped? yang:gauge64
| +--ro pps-dropped? yang:gauge64 | +--rw attack-status? iana-signal:attack-status
| +--rw attack-status? iana-signal:attack-status +--:(signal-config)
+--:(signal-config) | +--rw sid uint32
| +--rw sid uint32 | +--rw mitigating-config
| +--rw mitigating-config | | +--rw heartbeat-interval
| | +--rw heartbeat-interval | | | +--ro max-value? uint16
| | | +--ro max-value? uint16 | | | +--ro min-value? uint16
| | | +--ro min-value? uint16 | | | +--rw current-value? uint16
| | | +--rw current-value? uint16 | | +--rw missing-hb-allowed
| | +--rw missing-hb-allowed | | | +--ro max-value? uint16
| | | +--ro max-value? uint16 | | | +--ro min-value? uint16
| | | +--ro min-value? uint16 | | | +--rw current-value? uint16
| | | +--rw current-value? uint16 | | +--rw probing-rate
| | +--rw probing-rate | | | +--ro max-value? uint16
| | | +--ro max-value? uint16 | | | +--ro min-value? uint16
| | | +--ro min-value? uint16 | | | +--rw current-value? uint16
| | | +--rw current-value? uint16 | | +--rw max-retransmit
| | +--rw max-retransmit | | | +--ro max-value? uint16
| | | +--ro max-value? uint16 | | | +--ro min-value? uint16
| | | +--ro min-value? uint16 | | | +--rw current-value? uint16
| | | +--rw current-value? uint16 | | +--rw ack-timeout
| | +--rw ack-timeout | | | +--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 | +--rw idle-config
| +--rw idle-config | +--rw heartbeat-interval
| +--rw heartbeat-interval | | +--ro max-value? uint16
| | +--ro max-value? uint16 | | +--ro min-value? uint16
| | +--ro min-value? uint16 | | +--rw current-value? uint16
| | +--rw current-value? uint16 | +--rw missing-hb-allowed
| +--rw missing-hb-allowed | | +--ro max-value? uint16
| | +--ro max-value? uint16 | | +--ro min-value? uint16
| | +--ro min-value? uint16 | | +--rw current-value? uint16
| | +--rw current-value? uint16 | +--rw probing-rate
| +--rw probing-rate | | +--ro max-value? uint16
| | +--ro max-value? uint16 | | +--ro min-value? uint16
| | +--ro min-value? uint16 | | +--rw current-value? uint16
| | +--rw current-value? uint16 | +--rw max-retransmit
| +--rw max-retransmit | | +--ro max-value? uint16
| | +--ro max-value? uint16 | | +--ro min-value? uint16
| | +--ro min-value? uint16 | | +--rw current-value? uint16
| | +--rw current-value? uint16 | +--rw ack-timeout
| +--rw ack-timeout | | +--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 +--:(heartbeat)
+--:(heartbeat) +--rw peer-hb-status boolean
+--rw peer-hb-status boolean ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="iana-yang" numbered="true" toc="default">
<section anchor="iana-yang" title="IANA DOTS Signal Channel YANG Module"> <name>IANA DOTS Signal Channel YANG Module</name>
<t><figure> <sourcecode name="iana-dots-signal-channel@2020-05-28.yang" type="yang"
<artwork><![CDATA[<CODE BEGINS> file "iana-dots-signal-channel@2019- markers="true"><![CDATA[
01-17.yang"
module iana-dots-signal-channel { module iana-dots-signal-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel";
prefix iana-signal; prefix iana-signal;
organization organization
"IANA"; "IANA";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
Postal: ICANN Postal: ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
United States of America United States of America
Tel: +1 310 301 5800 Tel: +1 310 301 5800
<mailto:iana@iana.org>"; <mailto:iana@iana.org>";
description description
"This module contains a collection of YANG data types defined "This module contains a collection of YANG data types defined
by IANA and used for DOTS signal channel protocol. by IANA and used for DOTS signal channel protocol.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
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 8782; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-01-17 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
typedef status { typedef status {
type enumeration { type enumeration {
enum attack-mitigation-in-progress { enum attack-mitigation-in-progress {
value 1; value 1;
description description
"Attack mitigation setup 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 reroute 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 being 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 {
skipping to change at line 3183 skipping to change at line 3051
value 2; value 2;
description description
"The DOTS client determines that the attack is "The DOTS client determines that the attack is
successfully mitigated."; successfully mitigated.";
} }
} }
description description
"Enumeration for attack status codes."; "Enumeration for attack status codes.";
} }
} }
<CODE ENDS>]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section anchor="yrequest" numbered="true" toc="default">
<name>IETF DOTS Signal Channel YANG Module</name>
<t>This module uses the common YANG types defined in <xref target="RFC69
91" format="default"/>
and types defined in <xref target="RFC8783" format="default"/>.</t>
<section anchor="yrequest" title="IETF DOTS Signal Channel YANG Module"> <sourcecode name="ietf-dots-signal-channel@2020-05-28.yang" type="yang"
<t>This module uses the common YANG types defined in <xref markers="true"><![CDATA[
target="RFC6991"></xref> and types defined in <xref
target="I-D.ietf-dots-data-channel"></xref>.</t>
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-signal-channel@2019-
11-13.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;
reference "Section 4 of RFC 6991"; reference
"Section 4 of RFC 6991";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "Section 3 of RFC 6991"; reference
"Section 3 of RFC 6991";
} }
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix ietf-data;
reference reference
"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling "RFC 8783: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification"; (DOTS) Data Channel Specification";
} }
import iana-dots-signal-channel { import iana-dots-signal-channel {
prefix iana-signal; prefix iana-signal;
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Editor: Konda, Tirumaleswar Reddy Editor: Konda, Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:TirumaleswarReddy_Konda@McAfee.com>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Prashanth Patil Author: Prashanth Patil
<mailto:praspati@cisco.com> <mailto:praspati@cisco.com>
Author: Andrew Mortensen Author: Andrew Mortensen
<mailto:amortensen@arbor.net> <mailto:amortensen@arbor.net>
Author: Nik Teague Author: Nik Teague
<mailto:nteague@verisign.com>"; <mailto:nteague@ironmountain.co.uk>";
description description
"This module contains YANG definition for the signaling "This module contains YANG definition for the signaling
messages exchanged between a DOTS client and a DOTS server. messages exchanged between a DOTS client and a DOTS server.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
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 8782; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-11-13 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
/* /*
* Groupings * Groupings
*/ */
grouping mitigation-scope { grouping mitigation-scope {
description description
"Specifies the scope of the mitigation request."; "Specifies the scope of the mitigation request.";
list scope { list scope {
key "cuid mid"; key "cuid mid";
description description
"The scope of the request."; "The scope of the request.";
leaf cdid { leaf cdid {
type string; type string;
description description
"The cdid should be included by a server-domain "The cdid should be included by a server-domain
DOTS gateway to propagate the client domain DOTS gateway to propagate the client domain
identification information from the identification information from the
gateway's client-facing-side to the gateway's gateway's client-facing side to the gateway's
server-facing-side, and from the gateway's server-facing side, and from the gateway's
server-facing-side to the DOTS server. server-facing side to the DOTS server.
It may be used by the final DOTS server It may be used by the final DOTS server
for policy enforcement purposes."; for policy enforcement purposes.";
} }
leaf cuid { leaf cuid {
type string; type string;
description description
"A unique identifier that is "A unique identifier that is
generated by a DOTS client to prevent generated by a DOTS client to prevent
request collisions. It is expected that the request collisions. It is expected that the
skipping to change at line 3363 skipping to change at line 3230
} }
leaf conflict-cause { leaf conflict-cause {
type iana-signal:conflict-cause; type iana-signal:conflict-cause;
description description
"Indicates the cause of the conflict."; "Indicates the cause of the conflict.";
} }
leaf retry-timer { leaf retry-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"The DOTS client must not re-send the "The DOTS client must not resend the
same request that has a conflict before the expiry of same request that has a conflict before the expiry of
this timer."; this timer.";
} }
container conflict-scope { container conflict-scope {
description description
"Provides more information about the conflict scope."; "Provides more information about the conflict scope.";
uses ietf-data:target { uses ietf-data:target {
when "../conflict-cause = 'overlapping-targets'"; when "/dots-signal/scope/conflict-information/"
+ "conflict-cause = 'overlapping-targets'";
} }
leaf-list alias-name { leaf-list alias-name {
when "../../conflict-cause = 'overlapping-targets'"; when "../../conflict-cause = 'overlapping-targets'";
type string; type string;
description description
"Conflicting alias-name."; "Conflicting alias-name.";
} }
list acl-list { list acl-list {
when "../../conflict-cause = 'conflict-with-acceptlist'"; when "../../conflict-cause = 'conflict-with-acceptlist'";
key "acl-name"; key "acl-name";
skipping to change at line 3422 skipping to change at line 3290
the same DOTS client."; the same DOTS client.";
} }
} }
} }
leaf bytes-dropped { leaf bytes-dropped {
type yang:zero-based-counter64; type yang:zero-based-counter64;
units "bytes"; units "bytes";
config false; config false;
description description
"The total dropped byte count for the mitigation "The total dropped byte count for the mitigation
request since the attack mitigation is triggered. request since the attack mitigation was triggered.
The count wraps around when it reaches the maximum value The count wraps around when it reaches the maximum value
of counter64 for dropped bytes."; of counter64 for dropped bytes.";
} }
leaf bps-dropped { leaf bps-dropped {
type yang:gauge64; type yang:gauge64;
config false; config false;
description description
"The average number of dropped bits per second for "The average number of dropped bits per second for
the mitigation request since the attack the mitigation request since the attack
mitigation is triggered. This should be over mitigation was triggered. This should be over
five-minute intervals (that is, measuring bytes five-minute intervals (that is, measuring bytes
into five-minute buckets and then averaging these into five-minute buckets and then averaging these
buckets over the time since the mitigation was buckets over the time since the mitigation was
triggered)."; triggered).";
} }
leaf pkts-dropped { leaf pkts-dropped {
type yang:zero-based-counter64; type yang:zero-based-counter64;
config false; config false;
description description
"The total number of dropped packet count for the "The total number of dropped packet count for the
mitigation request since the attack mitigation is mitigation request since the attack mitigation was
triggered. The count wraps around when it reaches triggered. The count wraps around when it reaches
the maximum value of counter64 for dropped packets."; the maximum value of counter64 for dropped packets.";
} }
leaf pps-dropped { leaf pps-dropped {
type yang:gauge64; type yang:gauge64;
config false; config false;
description description
"The average number of dropped packets per second "The average number of dropped packets per second
for the mitigation request since the attack for the mitigation request since the attack
mitigation is triggered. This should be over mitigation was triggered. This should be over
five-minute intervals (that is, measuring packets five-minute intervals (that is, measuring packets
into five-minute buckets and then averaging these into five-minute buckets and then averaging these
buckets over the time since the mitigation was buckets over the time since the mitigation was
triggered)."; triggered).";
} }
leaf attack-status { leaf attack-status {
type iana-signal:attack-status; type iana-signal:attack-status;
description description
"Indicates the status of an attack as seen by the "Indicates the status of an attack as seen by the
DOTS client."; DOTS client.";
skipping to change at line 3525 skipping to change at line 3393
} }
leaf current-value { leaf current-value {
type uint16; type uint16;
default "15"; default "15";
description description
"Current missing-hb-allowed value."; "Current missing-hb-allowed value.";
} }
} }
container probing-rate { container probing-rate {
description description
"The limit for sending non-confirmable messages with "The limit for sending Non-confirmable messages with
no response."; no response.";
leaf max-value { leaf max-value {
type uint16; type uint16;
units "byte/second"; units "byte/second";
config false; config false;
description description
"Maximum acceptable probing-rate value."; "Maximum acceptable probing-rate value.";
} }
leaf min-value { leaf min-value {
type uint16; type uint16;
skipping to change at line 3713 skipping to change at line 3581
uses redirected-signal; uses redirected-signal;
} }
case heartbeat { case heartbeat {
description description
"DOTS heartbeats."; "DOTS heartbeats.";
leaf peer-hb-status { leaf peer-hb-status {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Indicates whether a DOTS agent receives heartbeats "Indicates whether a DOTS agent receives heartbeats
from its peer. The value is set to 'true' if the from its peer. The value is set to 'true' if the
DOTS agent is receiving heartbeat messages DOTS agent is receiving heartbeat messages
from its peer."; from its peer.";
} }
} }
} }
} }
} }
<CODE ENDS>]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
</section> </section>
<section anchor="mapping" numbered="true" toc="default">
<section anchor="mapping" title="YANG/JSON Mapping Parameters to CBOR"> <name>YANG/JSON Mapping Parameters to CBOR</name>
<t>All parameters in the payload of the DOTS signal channel MUST be <t>All parameters in the payload of the DOTS signal channel <bcp14>MUST</b
mapped to CBOR types as shown in Table 4 and are assigned an integer key cp14> be
to save space. <list style="symbols"> mapped to CBOR types as shown in <xref target="cbor-key-values" format="de
<t>Note: Implementers must check that the mapping output provided by fault"/>
and are assigned an integer key to save space. </t>
<ul empty="true" spacing="normal">
<li>Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of their YANG-to-CBOR encoding schemes is aligned with the content of
Table 4. For example, some CBOR and JSON types for enumerations and <xref target="cbor-key-values" format="default"/>. For example, some C
the 64-bit quantities can differ depending on the encoder used.</t> BOR and JSON types for enumerations and
</list></t> the 64-bit quantities can differ depending on the encoder used.</li>
</ul>
<t>The CBOR key values are divided into two types: <t>The CBOR key values are divided into two types:
comprehension-required and comprehension-optional. DOTS agents can comprehension-required and comprehension-optional. DOTS agents can
safely ignore comprehension-optional values they don't understand, but safely ignore comprehension-optional values they don't
understand, but they
cannot successfully process a request if it contains cannot successfully process a request if it contains
comprehension-required values that are not understood. The 4.00 response comprehension-required values that are not understood. The 4.00 response
SHOULD include a diagnostic payload describing the unknown <bcp14>SHOULD</bcp14> include a diagnostic payload describing the unknown
comprehension-required CBOR key values. The initial set of CBOR key comprehension-required CBOR key values. The initial set of CBOR key
values defined in this specification are of type values defined in this specification are of type
comprehension-required.</t> comprehension-required.</t>
<table anchor="cbor-key-values">
<t><figure> <name>CBOR Key Values Used in DOTS Signal Channel Messages &amp; Their
<artwork><![CDATA[ +----------------------+-------------+-----+----- Mappings to JSON and YANG</name>
----------+--------+ <thead>
| Parameter Name | YANG | CBOR| CBOR Major | JSON | <tr>
| | Type | Key | Type & | Type | <th>Parameter Name</th>
| | | | Information | | <th>YANG Type</th>
+----------------------+-------------+-----+---------------+--------+ <th>CBOR Key</th>
| ietf-dots-signal-cha | | | | | <th>CBOR Major Type &amp; Information</th>
| nnel:mitigation-scope| container | 1 | 5 map | Object | <th>JSON Type</th>
| scope | list | 2 | 4 array | Array | </tr>
| cdid | string | 3 | 3 text string | String | </thead>
| cuid | string | 4 | 3 text string | String | <tbody>
| mid | uint32 | 5 | 0 unsigned | Number | <tr>
| target-prefix | leaf-list | 6 | 4 array | Array | <td><t>ietf-dots-signal-<br/>channel:mitigation-scope</t></td>
| | inet: | | | | <td>container</td>
| | ip-prefix | | 3 text string | String | <td>1</td>
| target-port-range | list | 7 | 4 array | Array | <td>5 map</td>
| lower-port | inet: | | | | <td>Object</td>
| | port-number| 8 | 0 unsigned | Number | </tr>
| upper-port | inet: | | | | <tr>
| | port-number| 9 | 0 unsigned | Number | <td>scope</td>
| target-protocol | leaf-list | 10 | 4 array | Array | <td>list</td>
| | uint8 | | 0 unsigned | Number | <td>2</td>
| target-fqdn | leaf-list | 11 | 4 array | Array | <td>4 array</td>
| | inet: | | | | <td>Array</td>
| | domain-name| | 3 text string | String | </tr>
| target-uri | leaf-list | 12 | 4 array | Array | <tr>
| | inet:uri | | 3 text string | String | <td>cdid</td>
| alias-name | leaf-list | 13 | 4 array | Array | <td>string</td>
| | string | | 3 text string | String | <td>3</td>
| lifetime | int32 | 14 | 0 unsigned | Number | <td>3 text string</td>
| | | | 1 negative | Number | <td>String</td>
| mitigation-start | uint64 | 15 | 0 unsigned | String | </tr>
| status | enumeration | 16 | 0 unsigned | String | <tr>
| conflict-information | container | 17 | 5 map | Object | <td>cuid</td>
| conflict-status | enumeration | 18 | 0 unsigned | String | <td>string</td>
| conflict-cause | enumeration | 19 | 0 unsigned | String | <td>4</td>
| retry-timer | uint32 | 20 | 0 unsigned | Number | <td>3 text string</td>
| conflict-scope | container | 21 | 5 map | Object | <td>String</td>
| acl-list | list | 22 | 4 array | Array | </tr>
| acl-name | leafref | 23 | 3 text string | String | <tr>
| acl-type | leafref | 24 | 3 text string | String | <td>mid</td>
| bytes-dropped | yang:zero- | | | | <td>uint32</td>
| | based- | | | | <td>5</td>
| | counter64 | 25 | 0 unsigned | String | <td>0 unsigned</td>
| bps-dropped | yang:gauge64| 26 | 0 unsigned | String | <td>Number</td>
| pkts-dropped | yang:zero- | | | | </tr>
| | based- | | | | <tr>
| | counter64 | 27 | 0 unsigned | String | <td rowspan="2">target-prefix</td>
| pps-dropped | yang:gauge64| 28 | 0 unsigned | String | <td>leaf-list</td>
| attack-status | enumeration | 29 | 0 unsigned | String | <td>6</td>
| ietf-dots-signal- | | | | | <td>4 array</td>
| channel:signal-config| container | 30 | 5 map | Object | <td>Array</td>
| sid | uint32 | 31 | 0 unsigned | Number | </tr>
| mitigating-config | container | 32 | 5 map | Object | <tr>
| heartbeat-interval | container | 33 | 5 map | Object | <td>inet:ip-prefix</td>
| max-value | uint16 | 34 | 0 unsigned | Number | <td/>
| min-value | uint16 | 35 | 0 unsigned | Number | <td>3 text string</td>
| current-value | uint16 | 36 | 0 unsigned | Number | <td>String</td>
| missing-hb-allowed | container | 37 | 5 map | Object | </tr>
| max-retransmit | container | 38 | 5 map | Object | <tr>
| ack-timeout | container | 39 | 5 map | Object | <td>target-port-range</td>
| ack-random-factor | container | 40 | 5 map | Object | <td>list</td>
| max-value-decimal | decimal64 | 41 | 6 tag 4 | | <td>7</td>
| | | | [-2, integer]| String | <td>4 array</td>
| min-value-decimal | decimal64 | 42 | 6 tag 4 | | <td>Array</td>
| | | | [-2, integer]| String | </tr>
| current-value-decimal| decimal64 | 43 | 6 tag 4 | | <tr>
| | | | [-2, integer]| String | <td>lower-port</td>
| idle-config | container | 44 | 5 map | Object | <td>inet:port-number</td>
| trigger-mitigation | boolean | 45 | 7 bits 20 | False | <td>8</td>
| | | | 7 bits 21 | True | <td>0 unsigned</td>
| ietf-dots-signal-cha | | | | | <td>Number</td>
|nnel:redirected-signal| container | 46 | 5 map | Object | </tr>
| alt-server | string | 47 | 3 text string | String | <tr>
| alt-server-record | leaf-list | 48 | 4 array | Array | <td>upper-port</td>
| | inet: | | | | <td>inet:port-number</td>
| | ip-address | | 3 text string | String | <td>9</td>
| ietf-dots-signal-cha | | | | | <td>0 unsigned</td>
| nnel:heartbeat | container | 49 | 5 map | Object | <td>Number</td>
| probing-rate | container | 50 | 5 map | Object | </tr>
| peer-hb-status | boolean | 51 | 7 bits 20 | False | <tr>
| | | | 7 bits 21 | True | <td rowspan="2">target-protocol</td>
+----------------------+-------------+-----+---------------+--------+ <td>leaf-list</td>
<td>10</td>
Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their <td>4 array</td>
Mappings to JSON and YANG]]></artwork> <td>Array</td>
</figure></t> </tr>
<tr>
<td>uint8</td>
<td/>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td rowspan="2">target-fqdn</td>
<td>leaf-list</td>
<td>11</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>inet:domain-name</td>
<td/>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td rowspan="2">target-uri</td>
<td>leaf-list</td>
<td>12</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>inet:uri</td>
<td/>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td rowspan="2">alias-name</td>
<td>leaf-list</td>
<td>13</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>string</td>
<td/>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td rowspan="2">lifetime</td>
<td rowspan="2">int32</td>
<td rowspan="2">14</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>1 negative</td>
<td>Number</td>
</tr>
<tr>
<td>mitigation-start</td>
<td>uint64</td>
<td>15</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>status</td>
<td>enumeration</td>
<td>16</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>conflict-information</td>
<td>container</td>
<td>17</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>conflict-status</td>
<td>enumeration</td>
<td>18</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>conflict-cause</td>
<td>enumeration</td>
<td>19</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>retry-timer</td>
<td>uint32</td>
<td>20</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>conflict-scope</td>
<td>container</td>
<td>21</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>acl-list</td>
<td>list</td>
<td>22</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>acl-name</td>
<td>leafref</td>
<td>23</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>acl-type</td>
<td>leafref</td>
<td>24</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>bytes-dropped</td>
<td><t>yang:zero-based-<br/>counter64</t></td>
<td>25</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>bps-dropped</td>
<td>yang:gauge64</td>
<td>26</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>pkts-dropped</td>
<td><t>yang:zero-based-<br/>counter64</t></td>
<td>27</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>pps-dropped</td>
<td>yang:gauge64</td>
<td>28</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>attack-status</td>
<td>enumeration</td>
<td>29</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:signal-config</t></td>
<td>container</td>
<td>30</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>sid</td>
<td>uint32</td>
<td>31</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>mitigating-config</td>
<td>container</td>
<td>32</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>heartbeat-interval</td>
<td>container</td>
<td>33</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>max-value</td>
<td>uint16</td>
<td>34</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>min-value</td>
<td>uint16</td>
<td>35</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>current-value</td>
<td>uint16</td>
<td>36</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>missing-hb-allowed</td>
<td>container</td>
<td>37</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>max-retransmit</td>
<td>container</td>
<td>38</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>ack-timeout</td>
<td>container</td>
<td>39</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>ack-random-factor</td>
<td>container</td>
<td>40</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>max-value-decimal</td>
<td>decimal64</td>
<td>41</td>
<td>6 tag 4 [-2, integer]</td>
<td>String</td>
</tr>
<tr>
<td>min-value-decimal</td>
<td>decimal64</td>
<td>42</td>
<td>6 tag 4 [-2, integer]</td>
<td>String</td>
</tr>
<tr>
<td>current-value-decimal</td>
<td>decimal64</td>
<td>43</td>
<td>6 tag 4 [-2, integer]</td>
<td>String</td>
</tr>
<tr>
<td>idle-config</td>
<td>container</td>
<td>44</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td rowspan="2">trigger-mitigation</td>
<td rowspan="2">boolean</td>
<td rowspan="2">45</td>
<td>7 bits 20</td>
<td>False</td>
</tr>
<tr>
<td>7 bits 21</td>
<td>True</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:redirected-signal</t></td>
<td>container</td>
<td>46</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>alt-server</td>
<td>string</td>
<td>47</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td rowspan="2">alt-server-record</td>
<td>leaf-list</td>
<td>48</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>inet:ip-address</td>
<td/>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:heartbeat</t></td>
<td>container</td>
<td>49</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>probing-rate</td>
<td>container</td>
<td>50</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td rowspan="2">peer-hb-status</td>
<td rowspan="2">boolean</td>
<td rowspan="2">51</td>
<td>7 bits 20</td>
<td>False</td>
</tr>
<tr>
<td>7 bits 21</td>
<td>True</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="profile" numbered="true" toc="default">
<section anchor="profile" <name>(D)TLS Protocol Profile and Performance Considerations</name>
title="(D)TLS Protocol Profile and Performance Considerations"> <section numbered="true" toc="default">
<section title="(D)TLS Protocol Profile"> <name>(D)TLS Protocol Profile</name>
<t>This section defines the (D)TLS protocol profile of DOTS signal <t>This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS.</t> channel over (D)TLS and DOTS data channel over TLS.</t>
<t>There are known attacks on (D)TLS, such as man-in-the-middle and <t>There are known attacks on (D)TLS, such as man-in-the-middle and
protocol downgrade attacks. These are general attacks on (D)TLS and, protocol downgrade attacks. These are general attacks on (D)TLS and,
as such, they are not specific to DOTS over (D)TLS; refer to the as such, they are not specific to DOTS over (D)TLS; refer to the
(D)TLS RFCs for discussion of these security issues. DOTS agents MUST (D)TLS RFCs for discussion of these security issues. DOTS agents <bcp14> MUST</bcp14>
adhere to the (D)TLS implementation recommendations and security adhere to the (D)TLS implementation recommendations and security
considerations of <xref target="RFC7525"></xref> except with respect considerations of <xref target="RFC7525" format="default"/> except with
to (D)TLS version. Since DOTS signal channel encryption relying upon respect
(D)TLS is virtually a green-field deployment, DOTS agents MUST to (D)TLS version. Because DOTS signal channel encryption relying upon
(D)TLS is virtually a greenfield deployment, DOTS agents <bcp14>MUST</bc
p14>
implement only (D)TLS 1.2 or later.</t> implement only (D)TLS 1.2 or later.</t>
<t>When a DOTS client is configured with a domain name of the DOTS <t>When a DOTS client is configured with a domain name of the DOTS
server, and connects to its configured DOTS server, the server may server, and it 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 <bcp14>MUST</bcp14> verify the entire cert
path per <xref target="RFC5280"></xref>. Additionally, the DOTS client ification
MUST use <xref target="RFC6125"></xref> validation techniques to path per <xref target="RFC5280" format="default"/>. Additionally, the DO
TS client
<bcp14>MUST</bcp14> use <xref target="RFC6125" format="default"/> valida
tion techniques to
compare the domain name with the certificate provided. Certification compare the domain name with the certificate provided. Certification
authorities that issue DOTS server certificates SHOULD support the authorities that issue DOTS server certificates <bcp14>SHOULD</bcp14> su
DNS-ID and SRV-ID identifier types. DOTS server SHOULD prefer the use pport the
DNS-ID and SRV-ID identifier types. DOTS servers <bcp14>SHOULD</bcp14> p
refer the use
of DNS-ID and SRV-ID over CN-ID identifier types in certificate of DNS-ID and SRV-ID over CN-ID identifier types in certificate
requests (as described in Section 2.3 of <xref requests (as described in <xref target="RFC6125" section="2.3" sectionFo
target="RFC6125"></xref>) and the wildcard character '*' SHOULD NOT be rmat="of" format="default"/>), and the wildcard character '*' <bcp14>SHOULD NOT<
/bcp14> be
included in the presented identifier. DOTS doesn't use URI-IDs for included in the presented identifier. DOTS doesn't use URI-IDs for
server identity verification.</t> server identity verification.</t>
<t>A key challenge to deploying DOTS is the provisioning of DOTS <t>A key challenge to deploying DOTS is the provisioning of DOTS
clients, including the distribution of keying material to DOTS clients clients, including the distribution of keying material to DOTS clients
to enable the required mutual authentication of DOTS agents. to enable the required mutual authentication of DOTS agents.
Enrollment over Secure Transport (EST) <xref target="RFC7030"></xref> Enrollment over Secure Transport (EST) <xref target="RFC7030" format="de fault"/>
defines a method of certificate enrollment by which domains operating defines a method of certificate enrollment by which domains operating
DOTS servers may provide DOTS clients with all the necessary DOTS servers may provide DOTS clients with all the necessary
cryptographic keying material, including a private key and a cryptographic keying material, including a private key and a
certificate to authenticate themselves. One deployment option is DOTS certificate, to authenticate themselves. One deployment option is to hav e DOTS
clients behave as EST clients for certificate enrollment from an EST clients behave as EST clients for certificate enrollment from an EST
server provisioned by the mitigation provider. This document does not server provisioned by the mitigation provider. This document does not
specify which EST or other mechanism the DOTS client uses to achieve specify which EST or other mechanism the DOTS client uses to achieve
initial enrollment.</t> initial enrollment.</t>
<t>The Server Name Indication (SNI) extension <xref target="RFC6066" for
<t>The Server Name Indication (SNI) extension <xref mat="default"/> i
target="RFC6066"></xref> defines a mechanism for a client to tell a defines a mechanism for a client to tell a
(D)TLS server the name of the server it wants to contact. This is a (D)TLS server the name of the server it wants to contact. This is a
useful extension for hosting environments where multiple virtual useful extension for hosting environments where multiple virtual
servers are reachable over a single IP address. The DOTS client may or servers are reachable over a single IP address. The DOTS client may or
may not know if it is interacting with a DOTS server in a virtual may not know if it is interacting with a DOTS server in a virtual
server hosting environment, so the DOTS client SHOULD include the DOTS server hosting environment, so the DOTS client <bcp14>SHOULD</bcp14> inc lude the DOTS
server FQDN in the SNI extension.</t> server FQDN in the SNI extension.</t>
<t>Implementations compliant with this profile <bcp14>MUST</bcp14> imple
<t>Implementations compliant with this profile MUST implement all of ment all of
the following items:</t> the following items:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>DTLS record replay detection
<t>DTLS record replay detection (Section 3.3 of <xref (<xref target="RFC6347" section="3.3" sectionFormat="of" format="def
target="RFC6347"></xref>) or an equivalent mechanism to protect ault"/>) or an equivalent mechanism to protect
against replay attacks.</t> against replay attacks.</li>
<li>DTLS session resumption without server-side state to resume
<t>DTLS session resumption without server-side state to resume session and convey the DOTS signal.</li>
session and convey the DOTS signal.</t> <li>At least one of raw public keys <xref target="RFC7250" format="def
ault"/>
<t>At least one of raw public keys <xref target="RFC7250"></xref> or PSK handshake <xref target="RFC4279" format="default"/> with (EC)
or PSK handshake <xref target="RFC4279"></xref> with (EC)DHE key DHE key
exchange which reduces the size of the ServerHello, and can be exchange. This reduces the size of the ServerHello. Also, this can b
used by DOTS agents that cannot obtain certificates.</t> e
</list></t> used by DOTS agents that cannot obtain certificates.</li>
</ul>
<t>Implementations compliant with this profile SHOULD implement all of <t>Implementations compliant with this profile <bcp14>SHOULD</bcp14> imp
lement 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:</t> signal channel message:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>TLS False Start <xref target="RFC7918" format="default"/>, which r
<t>TLS False Start <xref target="RFC7918"></xref> which reduces educes
round-trips by allowing the TLS client's second flight of messages round-trips by allowing the TLS client's second flight of messages
(ChangeCipherSpec) to also contain the DOTS signal. TLS False (ChangeCipherSpec) to also contain the DOTS signal. TLS False
Start is formally defined for use with TLS, but the same technique Start is formally defined for use with TLS, but the same technique
is applicable to DTLS as well.</t> is applicable to DTLS as well.</li>
<li>Cached Information Extension <xref target="RFC7924" format="defaul
<t>Cached Information Extension <xref target="RFC7924"></xref> t"/>
which avoids transmitting the server's certificate and certificate which avoids transmitting the server's certificate and certificate
chain if the client has cached that information from a previous chain if the client has cached that information from a previous
TLS handshake.</t> TLS handshake.</li>
</list></t> </ul>
<t>Compared to UDP, DOTS signal channel over TCP requires an <t>Compared to UDP, DOTS signal channel over TCP requires an
additional round-trip time (RTT) of latency to establish a TCP additional round-trip time (RTT) of latency to establish a TCP
connection. DOTS implementations are encouraged to implement TCP Fast connection. DOTS implementations are encouraged to implement TCP Fast
Open <xref target="RFC7413"></xref> to eliminate that RTT.</t> Open <xref target="RFC7413" format="default"/> to eliminate that RTT.</t >
</section> </section>
<section anchor="DTLS" numbered="true" toc="default">
<section anchor="DTLS" title="(D)TLS 1.3 Considerations"> <name>(D)TLS 1.3 Considerations</name>
<t>TLS 1.3 provides critical latency improvements for connection <t>TLS 1.3 provides critical latency improvements for connection
establishment over TLS 1.2. The DTLS 1.3 protocol <xref establishment over TLS 1.2. The DTLS 1.3 protocol
target="I-D.ietf-tls-dtls13"></xref> is based upon the TLS 1.3 <xref target="I-D.ietf-tls-dtls13" format="default"/> is based upon the
TLS 1.3
protocol and provides equivalent security guarantees. (D)TLS 1.3 protocol and provides equivalent security guarantees. (D)TLS 1.3
provides two basic handshake modes the DOTS signal channel can take provides two basic handshake modes the DOTS signal channel can take
advantage of:</t> advantage of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A full handshake mode in which a DOTS client can send a DOTS 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.</t> assumes no packet loss is experienced.
</li>
<t>0-RTT mode in which the DOTS client can authenticate itself and <li>
0-RTT mode in which the DOTS client can authenticate itself and
send DOTS mitigation request messages in the first message, thus send DOTS mitigation request messages in the first message, thus
reducing handshake latency. 0-RTT only works if the DOTS client reducing handshake latency. 0-RTT only works if the DOTS client
has previously communicated with that DOTS server, which is very has previously communicated with that DOTS server, which is very
likely with the DOTS signal channel. <vspace blankLines="1" />The likely with the DOTS signal channel.
DOTS client has to establish a (D)TLS session with the DOTS server </li>
during 'idle' time and share a PSK. <vspace </ul>
blankLines="1" />During a DDoS attack, the DOTS client can use the <t>The DOTS client has to establish a (D)TLS session with the DOTS s
erver
during 'idle' time and share a PSK. </t>
<t>During a DDoS attack, the DOTS client can use the
(D)TLS session to convey the DOTS mitigation request message and, (D)TLS session to convey the DOTS mitigation request message and,
if there is no response from the server after multiple retries, if there is no response from the server after multiple retries,
the DOTS client can resume the (D)TLS session in 0-RTT mode using the DOTS client can resume the (D)TLS session in 0-RTT mode using
PSK. <vspace blankLines="1" />DOTS servers that support (D)TLS 1.3 PSK. </t>
MAY allow DOTS clients to send early data (0-RTT). DOTS clients <t>DOTS servers that support (D)TLS 1.3
MUST NOT send "CoAP Ping" as early data; such messages MUST be <bcp14>MAY</bcp14> allow DOTS clients to send early data (0-RTT). DO
rejected by DOTS servers. Section 8 of <xref TS clients
target="RFC8446"></xref> discusses some mechanisms to implement to <bcp14>MUST NOT</bcp14> send "CoAP Ping" as early data; such message
s <bcp14>MUST</bcp14> be
rejected by DOTS servers. <xref target="RFC8446" section="8" section
Format="of" format="default"/>
discusses some mechanisms to implement in order to
limit the impact of replay attacks on 0-RTT data. If the DOTS limit the impact of replay attacks on 0-RTT data. If the DOTS
server accepts 0-RTT, it MUST implement one of these mechanisms to server accepts 0-RTT, it <bcp14>MUST</bcp14> implement one of these mechanisms to
prevent replay at the TLS layer. A DOTS server can reject 0-RTT by prevent replay at the TLS layer. A DOTS server can reject 0-RTT by
sending a TLS HelloRetryRequest. <vspace blankLines="1" />The DOTS sending a TLS HelloRetryRequest. </t>
signal channel messages sent as early data by the DOTS client are <t>The DOTS signal channel messages sent as early data by the DOTS
idempotent requests. As a reminder, the Message ID (Section 3 of client are idempotent requests. As a reminder, the Message ID
<xref target="RFC7252"></xref>) is changed each time a new CoAP (<xref target="RFC7252" section="3" sectionFormat="of" format="defau
request is sent, and the Token (Section 5.3.1 of <xref lt"/>)
target="RFC7252"></xref>) is randomized in each CoAP request. The is changed each time a new CoAP request is sent, and the Token
DOTS server(s) MUST use the Message ID and the Token in the DOTS (<xref target="RFC7252" section="5.3.1" sectionFormat="of" format="d
signal channel message to detect replay of early data at the efault"/>)
application layer, and accept 0-RTT data at most once from the is randomized in each CoAP request.
The DOTS server(s) <bcp14>MUST</bcp14> use
the Message ID and the Token in the DOTS signal channel message to
detect replay of early data at the
application layer and accept 0-RTT data at most once from the
same DOTS client. This anti-replay defense requires sharing the same DOTS client. This anti-replay defense requires sharing the
Message ID and the Token in the 0-RTT data between DOTS servers in Message ID and the Token in the 0-RTT data between DOTS servers in
the DOTS server domain. DOTS servers do not rely on transport the DOTS server domain. DOTS servers do not rely on transport
coordinates to identify DOTS peers. As specified in <xref coordinates to identify DOTS peers. As specified in
target="post"></xref>, DOTS servers couple the DOTS signal channel <xref target="post" format="default"/>, DOTS servers couple the DOTS
signal channel
sessions using the DOTS client identity and optionally the 'cdid' sessions using the DOTS client identity and optionally the 'cdid'
parameter value. Furthermore, 'mid' value is monotonically parameter value. Furthermore, the 'mid' value is monotonically
increased by the DOTS client for each mitigation request, increased by the DOTS client for each mitigation request, thus
attackers replaying mitigation requests with lower numeric 'mid' attackers that replay mitigation requests with lower numeric 'mid'
values and overlapping scopes with mitigation requests having values and overlapping scopes with mitigation requests having
higher numeric 'mid' values will be rejected systematically by the higher numeric 'mid' values will be rejected systematically by the
DOTS server. Likewise, 'sid' value is monotonically increased by DOTS server. Likewise, the 'sid' value is monotonically increased by
the DOTS client for each configuration request (<xref the DOTS client for each configuration request
target="convey"></xref>), attackers replaying configuration (<xref target="convey" format="default"/>); attackers replaying conf
iguration
requests with lower numeric 'sid' values will be rejected by the requests with lower numeric 'sid' values will be rejected by the
DOTS server if it maintains a higher numeric 'sid' value for this DOTS server if it maintains a higher numeric 'sid' value for this
DOTS client. <vspace blankLines="1" />Owing to the aforementioned DOTS client. </t>
<t>Owing to the aforementioned
protections, all DOTS signal channel requests are safe to transmit protections, all DOTS signal channel requests are safe to transmit
in TLS 1.3 as early data. Refer to <xref in TLS 1.3 as early data. Refer to <xref target="I-D.boucadair-dots-
target="I-D.boucadair-dots-earlydata"></xref> for more details. earlydata" format="default"/> for more details.
<vspace blankLines="1" />A simplified TLS 1.3 handshake with 0-RTT </t>
DOTS mitigation request message exchange is shown in <xref <t>A simplified TLS 1.3 handshake with 0-RTT
target="Figure24"></xref>.<figure anchor="Figure24" DOTS mitigation request message exchange is shown in <xref target="F
title="A Simplified TLS 1.3 Handshake with 0-RTT"> igure24" format="default"/>.</t>
<artwork align="left"><![CDATA[ DOTS Client <figure anchor="Figure24">
DOTS Server <name>A Simplified TLS 1.3 Handshake with 0-RTT</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
DOTS Client DOTS Server
ClientHello ClientHello
(0-RTT DOTS signal message) (0-RTT DOTS signal message)
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{Finished} {Finished}
<-------- [DOTS signal message] <-------- [DOTS signal message]
(end_of_early_data) (end_of_early_data)
{Finished} --------> {Finished} -------->
[DOTS signal message] <-------> [DOTS signal message] [DOTS signal message] <-------> [DOTS signal message]
Note that: Note that:
() Indicates messages protected 0-RTT keys () Indicates messages protected 0-RTT keys
{} Indicates messages protected using handshake keys {} Indicates messages protected using handshake keys
[] Indicates messages protected using 1-RTT keys]]></artwork> [] Indicates messages protected using 1-RTT keys
</figure></t> ]]></artwork>
</list></t> </figure>
</section> </section>
<section anchor="mtu" numbered="true" toc="default">
<section anchor="mtu" title="DTLS MTU and Fragmentation"> <name>DTLS MTU and Fragmentation</name>
<t>To avoid DOTS signal message fragmentation and the subsequent <t>To avoid DOTS signal message fragmentation and the subsequent
decreased probability of message delivery, DOTS agents MUST ensure decreased probability of message delivery, DOTS agents <bcp14>MUST</bcp1
that the DTLS record fit within a single datagram. As a reminder, DTLS 4> ensure
that the DTLS record fits within a single datagram. As a reminder, DTLS
handles fragmentation and reassembly only for handshake messages and handles fragmentation and reassembly only for handshake messages and
not for the application data (Section 4.1.1 of <xref not for the application data (<xref target="RFC6347" section="4.1.1" sec
target="RFC6347"></xref>). If the PMTU cannot be discovered, DOTS tionFormat="of" format="default"/>).
agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every If the path MTU (PMTU) cannot be discovered, DOTS
agents <bcp14>MUST</bcp14> assume a PMTU of 1280 bytes, as IPv6 requires
that every
link in the Internet have an MTU of 1280 octets or greater as link in the Internet have an MTU of 1280 octets or greater as
specified in <xref target="RFC8200"></xref>. If IPv4 support on legacy specified in <xref target="RFC8200" format="default"/>. If IPv4 support on legacy
or otherwise unusual networks is a consideration and the PMTU is or otherwise unusual networks is a consideration and the PMTU is
unknown, DOTS implementations MAY assume on a PMTU of 576 bytes for unknown, DOTS implementations <bcp14>MAY</bcp14> assume a PMTU of 576 by tes for
IPv4 datagrams, as every IPv4 host must be capable of receiving a IPv4 datagrams, as every IPv4 host must be capable of receiving a
packet whose length is equal to 576 bytes as discussed in <xref packet whose length is equal to 576 bytes as discussed in <xref target="
target="RFC0791"></xref> and <xref target="RFC1122"></xref>.</t> RFC0791" format="default"/> and <xref target="RFC1122" format="default"/>.</t>
<t>The DOTS client must consider the amount of record expansion <t>The DOTS client must consider the amount of record expansion
expected by the DTLS processing when calculating the size of CoAP expected by the DTLS processing when calculating the size of the CoAP
message that fits within the path MTU. Path MTU MUST be greater than message that fits within the PMTU. PMTU <bcp14>MUST</bcp14> be greater t
han
or equal to [CoAP message size + DTLS 1.2 overhead of 13 octets + or equal to [CoAP message size + DTLS 1.2 overhead of 13 octets +
authentication overhead of the negotiated DTLS cipher suite + block authentication overhead of the negotiated DTLS cipher suite + block
padding] (Section 4.1.1.1 of <xref target="RFC6347"></xref>). If the padding] (<xref target="RFC6347" section="4.1.1.1" sectionFormat="of" fo
total request size exceeds the path MTU then the DOTS client MUST rmat="default"/>). If the
total request size exceeds the PMTU, then the DOTS client <bcp14>MUST</b
cp14>
split the DOTS signal into separate messages; for example, the list of split the DOTS signal into separate messages; for example, the list of
addresses in the 'target-prefix' parameter could be split into addresses in the 'target-prefix' parameter could be split into
multiple lists and each list conveyed in a new PUT request.</t> multiple lists and each list conveyed in a new PUT request.</t>
<aside><t>Implementation Note: DOTS choice of message size parameters wo
<t>Implementation Note: DOTS choice of message size parameters works rks
well with IPv6 and with most of today's IPv4 paths. However, with well with IPv6 and with most of today's IPv4 paths. However, with
IPv4, it is harder to safely make sure that there is no IP IPv4, it is harder to safely make sure that there is no IP
fragmentation. If the IPv4 path MTU is unknown, implementations may fragmentation. If the IPv4 PMTU is unknown, implementations may
want to limit themselves to more conservative IPv4 datagram sizes such want to limit themselves to more conservative IPv4 datagram sizes such
as 576 bytes, as per <xref target="RFC0791"></xref>.</t> as 576 bytes, per <xref target="RFC0791" format="default"/>.</t></aside>
</section> </section>
</section> </section>
<section anchor="mutauth" numbered="true" toc="default">
<section anchor="mutauth" <name>Mutual Authentication of DOTS Agents &amp; Authorization of DOTS Cli
title="Mutual Authentication of DOTS Agents &amp; Authorization of ents</name>
DOTS Clients"> <t>(D)TLS based upon client certificates can be used for mutual
<t>(D)TLS based upon client certificate can be used for mutual
authentication between DOTS agents. If, for example, a DOTS gateway is authentication between DOTS agents. If, for example, a DOTS gateway is
involved, DOTS clients and DOTS gateways must perform mutual involved, DOTS clients and DOTS gateways must perform mutual
authentication; only authorized DOTS clients are allowed to send DOTS authentication; only authorized DOTS clients are allowed to send DOTS
signals to a DOTS gateway. The DOTS gateway and the DOTS server must signals to a DOTS gateway. The DOTS gateway and the DOTS server must
perform mutual authentication; a DOTS server only allows DOTS signal perform mutual authentication; a DOTS server only allows DOTS signal
channel messages from an authorized DOTS gateway, thereby creating a channel messages from an authorized DOTS gateway, thereby creating a
two-link chain of transitive authentication between the DOTS client and two-link chain of transitive authentication between the DOTS client and
the DOTS server.</t> the DOTS server.</t>
<t>The DOTS server should support certificate-based client <t>The DOTS server should support certificate-based client
authentication. The DOTS client should respond to the DOTS server's TLS authentication. The DOTS client should respond to the DOTS server's TLS
CertificateRequest message with the PKIX certificate held by the DOTS CertificateRequest message with the PKIX certificate held by the DOTS
client. DOTS client certificate validation must be performed as per client. DOTS client certificate validation must be performed per
<xref target="RFC5280"></xref> and the DOTS client certificate must <xref target="RFC5280" format="default"/>, and the DOTS client certificate
conform to the <xref target="RFC5280"></xref> certificate profile. If a must
conform to the <xref target="RFC5280" format="default"/> certificate profi
le. If a
DOTS client does not support TLS client certificate authentication, it DOTS client does not support TLS client certificate authentication, it
must support pre-shared key based or raw public key based client must support client authentication based on pre-shared key or raw public k
authentication.</t> ey.</t>
<figure anchor="Figure12">
<t><figure anchor="Figure12" <name>Example of Authentication and Authorization of DOTS Agents</name>
title="Example of Authentication and Authorization of DOTS Agents"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +----------------------------------- +---------------------------------------------+
----------+ | example.com domain +---------+ |
| example.com domain +---------+ | | | AAA | |
| | AAA | | | +---------------+ | Server | |
| +---------------+ | Server | | | | Application | +------+--+ |
| | Application | +------+--+ | | | server +<---------------+ ^ |
| | server +<---------------+ ^ | | | (DOTS client) | | | |
| | (DOTS client) | | | | | +---------------+ | | |
| +---------------+ | | | | V V | example.net domain
| V V | example.net domain | +-----+----+--+ | +---------------+
| +-----+----+--+ | +---------------+ | +--------------+ | | | | |
| +--------------+ | | | | | | | Guest +<----x---->+ DOTS +<----->+ DOTS |
| | Guest +<----x---->+ DOTS +<------>+ DOTS | | | (DOTS client)| | gateway | | | server |
| | (DOTS client)| | gateway | | | server | | +--------------+ | | | | |
| +--------------+ | | | | | | +----+--------+ | +---------------+
| +----+--------+ | +---------------+ | ^ |
| ^ | | | |
| | | | +----------------+ | |
| +----------------+ | | | | DDoS detector | | |
| | DDoS detector | | | | | (DOTS client) +<-------------+ |
| | (DOTS client) +<-------------+ | | +----------------+ |
| +----------------+ | +---------------------------------------------+
+---------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> ---------------------------------------------+
</figure>
<t>In the example depicted in <xref target="Figure12"></xref>, the DOTS <t>In the example depicted in <xref target="Figure12" format="default"/>,
the DOTS
gateway and DOTS clients within the 'example.com' domain mutually gateway and DOTS clients within the 'example.com' domain mutually
authenticate. After the DOTS gateway validates the identity of a DOTS authenticate. After the DOTS gateway validates the identity of a DOTS
client, it communicates with the AAA server in the 'example.com' domain client, it communicates with the AAA server in the 'example.com' domain
to determine if the DOTS client is authorized to request DDoS to determine if the DOTS client is authorized to request DDoS
mitigation. If the DOTS client is not authorized, a 4.01 (Unauthorized) mitigation. If the DOTS client is not authorized, a 4.01 (Unauthorized)
is returned in the response to the DOTS client. In this example, the is returned in the response to the DOTS client. In this example, the
DOTS gateway only allows the application server and DDoS attack detector DOTS gateway only allows the application server and DDoS attack detector
to request DDoS mitigation, but does not permit the user of type 'guest' to request DDoS mitigation, but does not permit the user of type 'guest'
to request DDoS mitigation.</t> to request DDoS mitigation.</t>
<t>Also, DOTS gateways and servers located in different domains must <t>Also, DOTS gateways and servers located in different domains must
perform mutual authentication (e.g., using certificates). A DOTS server perform mutual authentication (e.g., using certificates). A DOTS server
will only allow a DOTS gateway with a certificate for a particular will only allow a DOTS gateway with a certificate for a particular
domain to request mitigation for that domain. In reference to <xref domain to request mitigation for that domain. In reference to
target="Figure12"></xref>, the DOTS server only allows the DOTS gateway <xref target="Figure12" format="default"/>, the DOTS server only allows th
to request mitigation for 'example.com' domain and not for other e DOTS gateway
to request mitigation for the 'example.com' domain and not for other
domains.</t> domains.</t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t></t> <name>IANA Considerations</name>
<section anchor="port" numbered="true" toc="default">
<name>DOTS Signal Channel UDP and TCP Port Number</name>
<section anchor="port" <t>IANA has assigned the port number 4646 (the ASCII decimal value for
title="DOTS Signal Channel UDP and TCP Port Number"> ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP
<t>IANA is requested to assign the port number TBD to the DOTS signal from the "Service Name and Transport Protocol Port Number Registry"
channel protocol for both UDP and TCP from the "Service Name and available at
Transport Protocol Port Number Registry" available at <eref target="https://www.iana.org/assignments/service-names-port-number
https://www.iana.org/assignments/service-names-port-numbers/service-name s/" brackets="angle"/>.</t>
s-port-numbers.xhtml.</t> <ul empty="true" spacing="normal">
<li>
<dl newline="false" spacing="compact">
<dt>Service Name:</dt><dd>dots-signal</dd>
<dt>Port Number:</dt><dd>4646</dd>
<dt>Transport Protocol:</dt><dd>TCP</dd>
<dt>Description:</dt><dd>Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel</dd>
<dt>Assignee:</dt><dd>IESG</dd>
<dt>Contact:</dt><dd>IETF Chair</dd>
<dt>Registration Date:</dt><dd>2020-01-16</dd>
<dt>Reference:</dt><dd>[RFC8782]</dd>
</dl>
</li>
<li>
<dl newline="false" spacing="compact">
<dt>Service Name:</dt><dd>dots-signal</dd>
<dt>Port Number:</dt><dd>4646</dd>
<dt>Transport Protocol:</dt><dd>UDP</dd>
<dt>Description:</dt><dd>Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel</dd>
<dt>Assignee:</dt><dd>IESG</dd>
<dt>Contact:</dt><dd>IETF Chair</dd>
<dt>Registration Date:</dt><dd>2020-01-16</dd>
<dt>Reference:</dt><dd>[RFC8782]</dd>
</dl>
</li>
</ul>
<t>The assignment of port number 4646 is strongly suggested, as 4646
is the ASCII decimal value for ".." (DOTS).</t>
</section> </section>
<section anchor="uri" title="Well-Known 'dots' URI"> <section anchor="uri" numbered="true" toc="default">
<t>This document requests IANA to register the 'dots' well-known URI <name>Well-Known 'dots' URI</name>
(Table 5) in the Well-Known URIs registry <t>IANA has registered the 'dots' well-known URI
(https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml) (<xref target="tab-dots-uri" format="default"/>) in the Well-Known URIs
as defined by <xref target="RFC8615"></xref>:<figure> registry
<artwork><![CDATA[ +----------+----------------+------------------ (<eref target="https://www.iana.org/assignments/well-known-uris/well-kno
---+-----------------+ wn-uris.xhtml" brackets="angle"/>)
| URI | Change | Specification | Related | as defined by <xref target="RFC8615" format="default"/>:</t>
| suffix | controller | document(s) | information | <table anchor="tab-dots-uri">
+----------+----------------+---------------------+-----------------+ <name>'dots' Well-Known URI</name>
| dots | IETF | [RFCXXXX] | None | <thead>
+----------+----------------+---------------------+-----------------+ <tr>
<th>URI Suffix</th>
Table 5: 'dots' well-known URI]]></artwork> <th>Change Controller</th>
</figure></t> <th>Reference</th>
<th>Status</th>
<th>Related information</th>
</tr>
</thead>
<tbody>
<tr>
<td>dots</td>
<td>IETF</td>
<td>[RFC8782]</td>
<td>permanent</td>
<td>None</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="MediaReg" numbered="true" toc="default">
<name>Media Type Registration</name>
<t>IANA has registered the "application/dots+cbor"
media type in the "Media Types" registry <xref target="IANA-MediaTypes"
format="default"/>
in the manner described in <xref target="RFC6838" format="default"/>,
which can be used to indicate that the
content is a DOTS signal channel object: </t>
<section anchor="MediaReg" title="Media Type Registration"> <t>Type name: application</t>
<t>This document requests IANA to register the <spanx style="verb">appli <t>Subtype name: dots+cbor</t>
cation/dots+cbor</spanx> <t>Required parameters: N/A</t>
media type in the "Media Types" registry <xref <t>Optional parameters: N/A</t>
target="IANA.MediaTypes"></xref> in the manner described in <xref <t>Encoding considerations: binary</t>
target="RFC6838"></xref>, which can be used to indicate that the <t>Security considerations: See the Security Considerations
content is a DOTS signal channel object: <?rfc subcompact="yes"?><list section of [RFC8782]</t>
style="symbols"> <t>Interoperability considerations: N/A</t>
<t>Type name: application</t> <t>Published specification: [RFC8782]</t>
<t>Applications that use this media type: DOTS agents sending DOTS
<t>Subtype name: dots+cbor</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: binary</t>
<t>Security considerations: See the Security Considerations
section of [RFCXXXX]</t>
<t>Interoperability considerations: N/A</t>
<t>Published specification: [RFCXXXX]</t>
<t>Applications that use this media type: DOTS agents sending DOTS
messages over CoAP over (D)TLS.</t> messages over CoAP over (D)TLS.</t>
<t>Fragment identifier considerations: N/A</t>
<t>Fragment identifier considerations: N/A</t> <t>Additional information:</t>
<ul empty="true" spacing="compact">
<t>Additional information:<list style="empty"> <li>Deprecated alias names for this type: N/A</li>
<t>Magic number(s): N/A</t> <li>Magic number(s): N/A</li>
<li>File extension(s): N/A</li>
<t>File extension(s): N/A</t> <li>Macintosh file type code(s): N/A</li>
</ul>
<t>Macintosh file type code(s): N/A</t>
</list> <vspace /></t>
<t>Person &amp; email address to contact for further information:
<vspace /> IESG, iesg@ietf.org</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: See Authors' Addresses section.</t>
<t>Change controller: IESG</t>
<t>Provisional registration? No</t> <t>Person &amp; email address to contact for further information: IESG
</list></t> , iesg@ietf.org</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: See Authors' Addresses section.</t>
<t>Change controller: IESG</t>
<t>Provisional registration? No</t>
<?rfc subcompact="no"?>
</section> </section>
<section anchor="IANACoAPContentFormatRegistration" <section anchor="IANACoAPContentFormatRegistration" numbered="true" toc="d
title="CoAP Content-Formats Registration"> efault">
<t>This document requests IANA to register the CoAP Content-Format ID <name>CoAP Content-Formats Registration</name>
<t>IANA has registered the CoAP Content-Format ID
for the "application/dots+cbor" media type in the "CoAP for the "application/dots+cbor" media type in the "CoAP
Content-Formats" registry <xref Content-Formats" registry <xref target="IANA-CoAP-Content-Formats" forma
target="IANA.CoAP.Content-Formats"></xref> (0-255 range):<?rfc subcompac t="default"/>:</t>
t="yes"?></t> <ul spacing="compact">
<li>Media Type: application/dots+cbor</li>
<t><list style="symbols"> <li>Encoding: -</li>
<t>Media Type: application/dots+cbor</t> <li>ID: 271</li>
<li>Reference: [RFC8782]</li>
<t>Encoding: -</t> </ul>
<t>Id: TBD1</t>
<t>Reference: [RFCXXXX]</t>
</list></t>
<?rfc subcompact="no"?>
</section> </section>
<section anchor="IANACBORTagAssignment" title="CBOR Tag Registration"> <section anchor="IANACBORTagAssignment" numbered="true" toc="default">
<name>CBOR Tag Registration</name>
<t>This section defines the DOTS CBOR tag as another means for <t>This section defines the DOTS CBOR tag as another means for
applications to declare that a CBOR data structure is a DOTS signal applications to declare that a CBOR data structure is a DOTS signal
channel object. Its use is optional and is intended for use in cases channel object. Its use is optional and is intended for use in cases
in which this information would not otherwise be known. DOTS CBOR tag in which this information would not otherwise be known. The DOTS CBOR ta g
is not required for DOTS signal channel protocol version specified in is not required for DOTS signal channel protocol version specified in
this document. If present, the DOTS tag MUST prefix a DOTS signal this document. If present, the DOTS tag <bcp14>MUST</bcp14> prefix a DOT S signal
channel object.</t> channel object.</t>
<t>IANA has registered the DOTS signal channel
<t>This document requests IANA to register the DOTS signal channel CBOR tag in the "CBOR Tags" registry <xref target="IANA-CBOR-Tags" forma
CBOR tag in the "CBOR Tags" registry <xref t="default"/>:</t>
target="IANA.CBOR.Tags"></xref> using the 24-255 range:<?rfc subcompact= <ul spacing="compact">
"yes"?></t> <li>Tag: 271</li>
<li>Data Item: DDoS Open Threat Signaling (DOTS) signal channel
<t><list style="symbols"> object</li>
<t>CBOR Tag: TBD2 (please assign the same value as the <li>Semantics: DDoS Open Threat Signaling (DOTS) signal channel
Content-Format)</t> object, as defined in [RFC8782]</li>
<li>Reference: [RFC8782]</li>
<t>Data Item: DDoS Open Threat Signaling (DOTS) signal channel </ul>
object</t>
<t>Semantics: DDoS Open Threat Signaling (DOTS) signal channel
object, as defined in [RFCXXXX]</t>
<t>Description of Semantics: [RFCXXXX]</t>
</list></t>
<?rfc subcompact="no"?>
</section> </section>
<section anchor="reg" numbered="true" toc="default">
<name>DOTS Signal Channel Protocol Registry</name>
<t>IANA has created a new registry titled the "Distributed Denial-of-Ser
vice Open Threat Signaling (DOTS) Signal Channel" registry. The following sectio
ns define
subregistries.</t>
<section anchor="reg" title="DOTS Signal Channel Protocol Registry"> <section anchor="map" numbered="true" toc="default">
<t>The document requests IANA to create a new registry, entitled "DOTS <name>DOTS Signal Channel CBOR Key Values Subregistry</name>
Signal Channel Registry". The following sections define <t>IANA has created a new subregistry titled
sub-registries.</t>
<section anchor="map"
title="DOTS Signal Channel CBOR Key Values Sub-Registry">
<t>The document requests IANA to create a new sub-registry, entitled
"DOTS Signal Channel CBOR Key Values".</t> "DOTS Signal Channel CBOR Key Values".</t>
<t>The structure of this subregistry is provided in
<t>The structure of this sub-registry is provided in <xref <xref target="format" format="default"/>.
target="format"></xref>. <xref target="initial"></xref> provides how <xref target="initial" format="default"/> provides
the registry is initially populated with the values in Table 4.</t> the registry as initially populated with the values in
<xref target="tab-cbor-key-reg" format="default"/>.</t>
<section anchor="format" title="Registration Template"> <section anchor="format" numbered="true" toc="default">
<t><list style="hanging"> <name>Registration Template</name>
<t hangText="Parameter name:"><vspace />Parameter name as used <dl newline="true" spacing="normal">
in the DOTS signal channel.</t> <dt>Parameter name:</dt>
<dd>Parameter name as used
<t hangText="CBOR Key Value:"><vspace />Key value for the in the DOTS signal channel.</dd>
parameter. The key value MUST be an integer in the 1-65535 <dt>CBOR Key Value:</dt>
<dd>
<t>Key value for the
parameter. The key value <bcp14>MUST</bcp14> be an integer in th
e 1-65535
range. The key values of the comprehension-required range range. The key values of the comprehension-required range
(0x0001 - 0x3FFF) and of the comprehension-optional range (0x0001 - 0x3FFF) and of the comprehension-optional range
(0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of (0x8000 - 0xBFFF) are assigned by IETF Review
<xref target="RFC8126"></xref>). The key values of the (<xref target="RFC8126" section="4.8" sectionFormat="of" format="default"/>). Th
e key values of the
comprehension-optional range (0x4000 - 0x7FFF) are assigned by comprehension-optional range (0x4000 - 0x7FFF) are assigned by
Specification Required (Section 4.6 of <xref Specification Required
target="RFC8126"></xref>) and of the comprehension-optional (<xref target="RFC8126" section="4.6" sectionFormat="of" format="default"/>) and
range (0xC000 - 0xFFFF) are reserved for Private Use (Section of the comprehension-optional
4.1 of <xref target="RFC8126"></xref>).<vspace range (0xC000 - 0xFFFF) are reserved for Private Use
blankLines="1" />Registration requests for the 0x4000 - 0x7FFF (<xref target="RFC8126" section="4.1" sectionFormat="of" format="default"/>).</t
>
<t>Registration requests for the 0x4000 - 0x7FFF
range are evaluated after a three-week review period on the range are evaluated after a three-week review period on the
dots-signal-reg-review@ietf.org mailing list, on the advice of dots-signal-reg-review@ietf.org mailing list, on the advice of
one or more Designated Experts. However, to allow for the one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated allocation of values prior to publication, the Designated
Experts may approve registration once they are satisfied that Experts may approve registration once they are satisfied that
such a specification will be published. New registration such a specification will be published. New registration
requests should be sent in the form of an email to the review requests should be sent in the form of an email to the review
mailing list; the request should use an appropriate subject mailing list; the request should use an appropriate subject
(e.g., "Request to register CBOR Key Value for DOTS: (e.g., "Request to register CBOR Key Value for DOTS:
example"). IANA will only accept new registrations from the example"). IANA will only accept new registrations from the
Designated Experts, and will check that review was requested Designated Experts, and it will check that review was requested
on the mailing list in accordance with these on the mailing list in accordance with these
procedures.<vspace blankLines="1" />Within the review period, procedures.</t>
<t>Within the review period,
the Designated Experts will either approve or deny the the Designated Experts will either approve or deny the
registration request, communicating this decision to the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a successful. Registration requests that are undetermined for a
period longer than 21 days can be brought to the IESG's period longer than 21 days can be brought to the IESG's
attention (using the iesg@ietf.org mailing list) for attention (using the iesg@ietf.org mailing list) for
resolution.<vspace blankLines="1" />Criteria that should be resolution.</t>
applied by the Designated Experts includes determining whether <t>Criteria that should be
applied by the Designated Experts include determining whether
the proposed registration duplicates existing functionality, the proposed registration duplicates existing functionality,
whether it is likely to be of general applicability or whether whether it is likely to be of general applicability or whether
it is useful only for a single use case, and whether the it is useful only for a single use case, and whether the
registration description is clear. IANA must only accept registration description is clear. IANA must only accept
registry updates to the 0x4000 - 0x7FFF range from the registry updates to the 0x4000 - 0x7FFF range from the
Designated Experts and should direct all requests for Designated Experts and should direct all requests for
registration to the review mailing list. It is suggested that registration to the review mailing list. It is suggested that
multiple Designated Experts be appointed. In cases where a multiple Designated Experts be appointed. In cases where a
registration decision could be perceived as creating a registration decision could be perceived as creating a
conflict of interest for a particular Expert, that Expert conflict of interest for a particular Expert, that Expert
should defer to the judgment of the other Experts.</t> should defer to the judgment of the other Experts.</t>
</dd>
<t hangText="CBOR Major Type:"><vspace />CBOR Major type and <dt>CBOR Major Type:</dt>
optional tag for the parameter.</t> <dd>CBOR Major type and
optional tag for the parameter.</dd>
<t hangText="Change Controller:"><vspace />For Standards Track <dt>Change Controller:</dt>
<dd>For Standards Track
RFCs, list the "IESG". For others, give the name of the RFCs, list the "IESG". For others, give the name of the
responsible party. Other details (e.g., email address) may responsible party. Other details (e.g., email address) may
also be included.</t> also be included.</dd>
<dt>Specification Document(s):</dt>
<t hangText="Specification Document(s):"><vspace />Reference <dd>Reference
to the document or documents that specify the parameter, to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies preferably including URIs that can be used to retrieve copies
of the documents. An indication of the relevant sections may of the documents. An indication of the relevant sections may
also be included but is not required.</t> also be included but is not required.</dd>
</list></t> </dl>
</section> </section>
<section anchor="initial" numbered="true" toc="default">
<name>Initial Subregistry Content</name>
<section anchor="initial" title="Initial Sub-Registry Content"> <table anchor="tab-cbor-key-reg">
<t><figure> <name>Initial DOTS Signal Channel CBOR Key Values Registry</name>
<artwork><![CDATA[ +----------------------+-------+-------+--- <thead>
---------+---------------+ <tr>
| Parameter Name | CBOR | CBOR | Change | Specification | <th>Parameter Name</th>
| | Key | Major | Controller | Document(s) | <th>CBOR Key Value</th>
| | Value | Type | | | <th>CBOR Major Type</th>
+----------------------+-------+-------+------------+---------------+ <th>Change Controller</th>
| ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | <th>Specification Document(s)</th>
| nel:mitigation-scope | | | | | </tr>
| scope | 2 | 4 | IESG | [RFCXXXX] | </thead>
| cdid | 3 | 3 | IESG | [RFCXXXX] | <tbody>
| cuid | 4 | 3 | IESG | [RFCXXXX] | <tr>
| mid | 5 | 0 | IESG | [RFCXXXX] | <td>Reserved</td>
| target-prefix | 6 | 4 | IESG | [RFCXXXX] | <td>0</td>
| target-port-range | 7 | 4 | IESG | [RFCXXXX] | <td/>
| lower-port | 8 | 0 | IESG | [RFCXXXX] | <td/>
| upper-port | 9 | 0 | IESG | [RFCXXXX] | <td>[RFC8782]</td>
| target-protocol | 10 | 4 | IESG | [RFCXXXX] | </tr>
| target-fqdn | 11 | 4 | IESG | [RFCXXXX] | <tr>
| target-uri | 12 | 4 | IESG | [RFCXXXX] | <td><t>ietf-dots-signal-<br/>channel:mitigation-<br/>scope</t></t
| alias-name | 13 | 4 | IESG | [RFCXXXX] | d>
| lifetime | 14 | 0/1 | IESG | [RFCXXXX] | <td>1</td>
| mitigation-start | 15 | 0 | IESG | [RFCXXXX] | <td>5</td>
| status | 16 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| conflict-information | 17 | 5 | IESG | [RFCXXXX] | <td>[RFC8782]</td>
| conflict-status | 18 | 0 | IESG | [RFCXXXX] | </tr>
| conflict-cause | 19 | 0 | IESG | [RFCXXXX] | <tr>
| retry-timer | 20 | 0 | IESG | [RFCXXXX] | <td>scope</td>
| conflict-scope | 21 | 5 | IESG | [RFCXXXX] | <td>2</td>
| acl-list | 22 | 4 | IESG | [RFCXXXX] | <td>4</td>
| acl-name | 23 | 3 | IESG | [RFCXXXX] | <td>IESG</td>
| acl-type | 24 | 3 | IESG | [RFCXXXX] | <td>[RFC8782]</td>
| bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | </tr>
| bps-dropped | 26 | 0 | IESG | [RFCXXXX] | <tr>
| pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | <td>cdid</td>
| pps-dropped | 28 | 0 | IESG | [RFCXXXX] | <td>3</td>
| attack-status | 29 | 0 | IESG | [RFCXXXX] | <td>3</td>
| ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | <td>IESG</td>
| channel:signal-config| | | | | <td>[RFC8782]</td>
| sid | 31 | 0 | IESG | [RFCXXXX] | </tr>
| mitigating-config | 32 | 5 | IESG | [RFCXXXX] | <tr>
| heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | <td>cuid</td>
| min-value | 34 | 0 | IESG | [RFCXXXX] | <td>4</td>
| max-value | 35 | 0 | IESG | [RFCXXXX] | <td>3</td>
| current-value | 36 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | <td>[RFC8782]</td>
| max-retransmit | 38 | 5 | IESG | [RFCXXXX] | </tr>
| ack-timeout | 39 | 5 | IESG | [RFCXXXX] | <tr>
| ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | <td>mid</td>
| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | <td>5</td>
| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | <td>0</td>
| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | <td>IESG</td>
| decimal | | | | | <td>[RFC8782]</td>
| idle-config | 44 | 5 | IESG | [RFCXXXX] | </tr>
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | <tr>
| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | <td>target-prefix</td>
| nel:redirected-signal| | | | | <td>6</td>
| alt-server | 47 | 3 | IESG | [RFCXXXX] | <td>4</td>
| alt-server-record | 48 | 4 | IESG | [RFCXXXX] | <td>IESG</td>
| ietf-dots-signal-chan| 49 | 5 | IESG | [RFCXXXX] | <td>[RFC8782]</td>
| nel:heartbeat | | | | | </tr>
| probing-rate | 50 | 5 | IESG | [RFCXXXX] | <tr>
| peer-hb-status | 51 | 7 | IESG | [RFCXXXX] | <td>target-port-range</td>
+----------------------+-------+-------+------------+---------------+ <td>7</td>
<td>4</td>
Table 6: Initial DOTS Signal Channel CBOR Key Values Registry <td>IESG</td>
]]></artwork> <td>[RFC8782]</td>
</figure></t> </tr>
<tr>
<td>lower-port</td>
<td>8</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>upper-port</td>
<td>9</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>target-protocol</td>
<td>10</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>target-fqdn</td>
<td>11</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>target-uri</td>
<td>12</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>alias-name</td>
<td>13</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>lifetime</td>
<td>14</td>
<td>0/1</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>mitigation-start</td>
<td>15</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>status</td>
<td>16</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>conflict-information</td>
<td>17</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>conflict-status</td>
<td>18</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>conflict-cause</td>
<td>19</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>retry-timer</td>
<td>20</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>conflict-scope</td>
<td>21</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>acl-list</td>
<td>22</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>acl-name</td>
<td>23</td>
<td>3</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>acl-type</td>
<td>24</td>
<td>3</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>bytes-dropped</td>
<td>25</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>bps-dropped</td>
<td>26</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>pkts-dropped</td>
<td>27</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>pps-dropped</td>
<td>28</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>attack-status</td>
<td>29</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:signal-<br/>config</t></td>
<td>30</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>sid</td>
<td>31</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>mitigating-config</td>
<td>32</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>heartbeat-interval</td>
<td>33</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>min-value</td>
<td>34</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>max-value</td>
<td>35</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>current-value</td>
<td>36</td>
<td>0</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>missing-hb-allowed</td>
<td>37</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>max-retransmit</td>
<td>38</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>ack-timeout</td>
<td>39</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>ack-random-factor</td>
<td>40</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>min-value-decimal</td>
<td>41</td>
<td>6tag4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>max-value-decimal</td>
<td>42</td>
<td>6tag4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>current-value-decimal</td>
<td>43</td>
<td>6tag4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>idle-config</td>
<td>44</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>trigger-mitigation</td>
<td>45</td>
<td>7</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:redirected-<br/>signal</t></
td>
<td>46</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>alt-server</td>
<td>47</td>
<td>3</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>alt-server-record</td>
<td>48</td>
<td>4</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td><t>ietf-dots-signal-<br/>channel:heartbeat</t></td>
<td>49</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>probing-rate</td>
<td>50</td>
<td>5</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>peer-hb-status</td>
<td>51</td>
<td>7</td>
<td>IESG</td>
<td>[RFC8782]</td>
</tr>
<tr>
<td>Unassigned</td>
<td>52-49151</td>
<td/>
<td/>
<td/>
</tr>
<tr>
<td>Reserved for Private Use</td>
<td>49152-65535</td>
<td/>
<td/>
<td>[RFC8782]</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="sc" title="Status Codes Sub-Registry"> <section anchor="sc" numbered="true" toc="default">
<t>The document requests IANA to create a new sub-registry, entitled <name>Status Codes Subregistry</name>
<t>IANA has created a new subregistry titled
"DOTS Signal Channel Status Codes". Codes in this registry are used "DOTS Signal Channel Status Codes". Codes in this registry are used
as valid values of 'status' parameter.</t> as valid values of 'status' parameter.</t>
<t>The registry is initially populated with the following <t>The registry is initially populated with the following
values:</t> values:</t>
<texttable style="full"> <table align="center">
<ttcol align="right">Code</ttcol> <name>Initial DOTS Signal Channel Status Codes</name>
<thead>
<ttcol>Label</ttcol> <tr>
<th align="right">Code</th>
<ttcol align="left">Description</ttcol> <th align="left">Label</th>
<th align="left">Description</th>
<ttcol>Reference</ttcol> <th align="left">Reference</th>
</tr>
<c>1</c> </thead>
<tbody>
<c>attack-mitigation-in-progress</c> <tr>
<td align="right"><t>0</t></td>
<c>Attack mitigation setup is in progress (e.g., changing the <td align="left"><t>Reserved</t></td>
<td align="left"/>
<td align="left"><t>[RFC8782]</t></td>
</tr>
<tr>
<td align="right"><t>1</t></td>
<td align="left"><t>attack-mitigation-<br/>in-progress</t></td>
<td align="left"><t>Attack mitigation setup is in progress (e.g.
, changing the
network path to redirect the inbound traffic to a DOTS network path to redirect the inbound traffic to a DOTS
mitigator).</c> mitigator).</t></td>
<td align="left"><t>[RFC8782]</t></td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>2</c> <td align="right"><t>2</t></td>
<td align="left"><t>attack-successfully-<br/>mitigated</t></td>
<c>attack-successfully-mitigated</c> <td align="left"><t>Attack is being successfully mitigated (e.g.
, traffic is
<c>Attack is being successfully mitigated (e.g., traffic is redirected to a DDoS mitigator and attack traffic is dropped).</t></
redirected to a DDoS mitigator and attack traffic is dropped).</c> td>
<td align="left"><t>[RFC8782]</t></td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>3</c> <td align="right"><t>3</t></td>
<td align="left"><t>attack-stopped</t></td>
<c>attack-stopped</c> <td align="left"><t>Attack has stopped and the DOTS client can w
ithdraw the
<c>Attack has stopped and the DOTS client can withdraw the mitigation request.</t></td>
mitigation request.</c> <td align="left"><t>[RFC8782]</t></td>
</tr>
<c>[RFCXXXX]</c> <tr>
<td align="right"><t>4</t></td>
<c>4</c> <td align="left"><t>attack-exceeded-<br/>capability</t></td>
<td align="left"><t>Attack has exceeded the mitigation provider
<c>attack-exceeded-capability</c> capability.</t></td>
<td align="left"><t>[RFC8782]</t></td>
<c>Attack has exceeded the mitigation provider capability.</c> </tr>
<tr>
<c>[RFCXXXX]</c> <td align="right"><t>5</t></td>
<td align="left"><t>dots-client-<br/>withdrawn-mitigation</t></t
<c>5</c> d>
<td align="left"><t>DOTS client has withdrawn the mitigation req
<c>dots-client-withdrawn-mitigation</c> uest and the
mitigation is active but terminating.</t></td>
<c>DOTS client has withdrawn the mitigation request and the <td align="left"><t>[RFC8782]</t></td>
mitigation is active but terminating.</c> </tr>
<tr>
<c>[RFCXXXX]</c> <td align="right"><t>6</t></td>
<td align="left"><t>attack-mitigation-<br/>terminated</t></td>
<c>6</c> <td align="left"><t>Attack mitigation is now terminated.</t></td
>
<c>attack-mitigation-terminated</c> <td align="left"><t>[RFC8782]</t></td>
</tr>
<c>Attack mitigation is now terminated.</c> <tr>
<td align="right"><t>7</t></td>
<c>[RFCXXXX]</c> <td align="left"><t>attack-mitigation-<br/>withdrawn</t></td>
<td align="left"><t>Attack mitigation is withdrawn.</t></td>
<c>7</c> <td align="left"><t>[RFC8782]</t></td>
</tr>
<c>attack-mitigation-withdrawn</c> <tr>
<td align="right"><t>8</t></td>
<c>Attack mitigation is withdrawn.</c> <td align="left"><t>attack-mitigation-<br/>signal-loss</t></td>
<td align="left"><t>Attack mitigation will be triggered for the
<c>[RFCXXXX]</c> mitigation request
only when the DOTS signal channel session is lost.</t></td>
<c>8</c> <td align="left"><t>[RFC8782]</t></td>
</tr>
<c>attack-mitigation-signal-loss</c> <tr>
<td align="right"><t>9-2147483647</t></td>
<c>Attack mitigation will be triggered for the mitigation request <td align="left"><t>Unassigned</t></td>
only when the DOTS signal channel session is lost.</c> <td align="left"/>
<td align="left"/>
<c>[RFCXXXX]</c> </tr>
</texttable> </tbody>
</table>
<t>New codes can be assigned via Standards Action <xref <t>New codes can be assigned via Standards Action <xref target="RFC812
target="RFC8126"></xref>.</t> 6" format="default"/>.</t>
</section> </section>
<section anchor="cs" title="Conflict Status Codes Sub-Registry"> <section anchor="cs" numbered="true" toc="default">
<t>The document requests IANA to create a new sub-registry, entitled <name>Conflict Status Codes Subregistry</name>
<t>IANA has created a new subregistry titled
"DOTS Signal Channel Conflict Status Codes". Codes in this registry "DOTS Signal Channel Conflict Status Codes". Codes in this registry
are used as valid values of 'conflict-status' parameter.</t> are used as valid values of 'conflict-status' parameter.</t>
<t>The registry is initially populated with the following <t>The registry is initially populated with the following
values:</t> values:</t>
<table align="center">
<texttable> <name>Initial DOTS Signal Channel Conflict Status Codes</name>
<ttcol>Code</ttcol> <thead>
<tr>
<ttcol>Label</ttcol> <th align="right">Code</th>
<th align="left">Label</th>
<ttcol>Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol>Reference</ttcol> </tr>
</thead>
<c>1</c> <tbody>
<tr>
<c>request-inactive-other-active</c> <td align="right">0</td>
<td align="left">Reserved</td>
<c>DOTS server has detected conflicting mitigation requests from <td align="left"/>
<td align="left">[RFC8782]</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left"><t>request-inactive-<br/>other-active</t></td>
<td align="left">DOTS server has detected conflicting mitigation
requests from
different DOTS clients. This mitigation request is currently different DOTS clients. This mitigation request is currently
inactive until the conflicts are resolved. Another mitigation inactive until the conflicts are resolved. Another mitigation
request is active.</c> request is active.</td>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>2</c> <td align="right">2</td>
<td align="left">request-active</td>
<c>request-active</c> <td align="left">DOTS server has detected conflicting mitigation
requests from
<c>DOTS server has detected conflicting mitigation requests from
different DOTS clients. This mitigation request is currently different DOTS clients. This mitigation request is currently
active.</c> active.</td>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>3</c> <td align="right">3</td>
<td align="left"><t>all-requests-<br/>inactive</t></td>
<c>all-requests-inactive</c> <td align="left">DOTS server has detected conflicting mitigation
requests from
<c>DOTS server has detected conflicting mitigation requests from
different DOTS clients. All conflicting mitigation requests are different DOTS clients. All conflicting mitigation requests are
inactive.</c> inactive.</td>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
</texttable> <tr>
<td align="right">4-2147483647</td>
<t>New codes can be assigned via Standards Action <xref <td align="left">Unassigned</td>
target="RFC8126"></xref>.</t> <td align="left"/>
<td align="left"/>
</tr>
</tbody>
</table>
<t>New codes can be assigned via Standards Action <xref target="RFC812
6" format="default"/>.</t>
</section> </section>
<section anchor="cc" title="Conflict Cause Codes Sub-Registry"> <section anchor="cc" numbered="true" toc="default">
<t>The document requests IANA to create a new sub-registry, entitled <name>Conflict Cause Codes Subregistry</name>
<t>IANA has created a new subregistry titled
"DOTS Signal Channel Conflict Cause Codes". Codes in this registry "DOTS Signal Channel Conflict Cause Codes". Codes in this registry
are used as valid values of 'conflict-cause' parameter.</t> are used as valid values of 'conflict-cause' parameter.</t>
<t>The registry is initially populated with the following <t>The registry is initially populated with the following
values:</t> values:</t>
<table align="center">
<texttable> <name>Initial DOTS Signal Channel Conflict Cause Codes</name>
<ttcol>Code</ttcol> <thead>
<tr>
<ttcol>Label</ttcol> <th align="right">Code</th>
<th align="left">Label</th>
<ttcol>Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol>Reference</ttcol> </tr>
</thead>
<c>1</c> <tbody>
<tr>
<c>overlapping-targets</c> <td align="right">0</td>
<td align="left">Reserved</td>
<c>Overlapping targets.</c> <td align="left"/>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>2</c> <td align="right">1</td>
<td align="left">overlapping-targets</td>
<c>conflict-with-acceptlist</c> <td align="left">Overlapping targets.</td>
<td align="left">[RFC8782]</td>
<c>Conflicts with an existing accept-list. This code is returned </tr>
<tr>
<td align="right">2</td>
<td align="left"><t>conflict-with-<br/>acceptlist</t></td>
<td align="left">Conflicts with an existing accept-list. This co
de is returned
when the DDoS mitigation detects source addresses/prefixes in the when the DDoS mitigation detects source addresses/prefixes in the
accept-listed ACLs are attacking the target.</c> accept-listed ACLs are attacking the target.</td>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>3</c> <td align="right">3</td>
<td align="left">cuid-collision</td>
<c>cuid-collision</c> <td align="left">CUID Collision. This code is returned when a DO
TS client uses a
<c>CUID Collision. This code is returned when a DOTS client uses a 'cuid' that is already used by another DOTS client.</td>
'cuid' that is already used by another DOTS client.</c> <td align="left">[RFC8782]</td>
</tr>
<c>[RFCXXXX]</c> <tr>
</texttable> <td align="right">4-2147483647</td>
<td align="left">Unassigned</td>
<t>New codes can be assigned via Standards Action <xref <td align="left"/>
target="RFC8126"></xref>.</t> <td align="left"/>
</tr>
</tbody>
</table>
<t>New codes can be assigned via Standards Action <xref target="RFC812
6" format="default"/>.</t>
</section> </section>
<section anchor="as" title="Attack Status Codes Sub-Registry"> <section anchor="as" numbered="true" toc="default">
<t>The document requests IANA to create a new sub-registry, entitled <name>Attack Status Codes Subregistry</name>
<t>IANA has created a new subregistry titled
"DOTS Signal Channel Attack Status Codes". Codes in this registry "DOTS Signal Channel Attack Status Codes". Codes in this registry
are used as valid values of 'attack-status' parameter.</t> are used as valid values of 'attack-status' parameter.</t>
<t>The registry is initially populated with the following <t>The registry is initially populated with the following
values:</t> values:</t>
<table align="center">
<texttable> <name>Initial DOTS Signal Channel Attack Status Codes</name>
<ttcol>Code</ttcol> <thead>
<tr>
<ttcol>Label</ttcol> <th align="right">Code</th>
<th align="left">Label</th>
<ttcol>Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol>Reference</ttcol> </tr>
</thead>
<c>1</c> <tbody>
<tr>
<c>under-attack</c> <td align="right">0</td>
<td align="left">Reserved</td>
<c>The DOTS client determines that it is still under attack.</c> <td align="left"/>
<td align="left">[RFC8782]</td>
<c>[RFCXXXX]</c> </tr>
<tr>
<c>2</c> <td align="right">1</td>
<td align="left">under-attack</td>
<c>attack-successfully-mitigated</c> <td align="left">The DOTS client determines that it is still und
er attack.</td>
<c>The DOTS client determines that the attack is successfully <td align="left">[RFC8782]</td>
mitigated.</c> </tr>
<tr>
<c>[RFCXXXX]</c> <td align="right">2</td>
</texttable> <td align="left"><t>attack-successfully-<br/>mitigated</t></td>
<td align="left">The DOTS client determines that the attack is s
<t>New codes can be assigned via Standards Action <xref uccessfully
target="RFC8126"></xref>.</t> mitigated.</td>
<td align="left">[RFC8782]</td>
</tr>
<tr>
<td align="right">3-2147483647</td>
<td align="left">Unassigned</td>
<td align="left"/>
<td align="left"/>
</tr>
</tbody>
</table>
<t>New codes can be assigned via Standards Action <xref target="RFC812
6" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="yang" title="DOTS Signal Channel YANG Modules"> <section anchor="yang" numbered="true" toc="default">
<t>This document requests IANA to register the following URIs in the <name>DOTS Signal Channel YANG Modules</name>
"ns" subregistry within the "IETF XML Registry" <xref <t>IANA has registered the following URIs in the
target="RFC3688"></xref>: <figure> "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-s ormat="default"/>: </t>
ignal-channel <ul empty="true" spacing="normal">
Registrant Contact: The IESG. <li>
XML: N/A; the requested URI is an XML namespace. <dl newline="false" spacing="compact">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-cha
nnel</dd>
<dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
</li>
<li>
<dl newline="false" spacing="compact">
<dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:iana-dots-signal-c
hannel</dd>
<dt>Registrant Contact:</dt> <dd>IANA.</dd>
<dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</d
d>
</dl>
</li>
</ul>
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel <t>IANA has registered the following YANG
Registrant Contact: IANA. modules in the "YANG Module Names" subregistry <xref target="RFC7950" fo
XML: N/A; the requested URI is an XML namespace. rmat="default"/>
]]></artwork> within the "YANG Parameters" registry.</t>
</figure>This document requests IANA to register the following YANG
modules in the "YANG Module Names" subregistry <xref
target="RFC7950"></xref> within the "YANG Parameters" registry.<figure>
<artwork><![CDATA[ Name: ietf-dots-signal-channel
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Maintained by IANA: N
Prefix: signal
Reference: RFC XXXX
Name: iana-dots-signal-channel <ul empty="true" spacing="normal">
Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel <li>
Maintained by IANA: Y <dl newline="false" spacing="compact">
Prefix: iana-signal <dt>Name:</dt> <dd>ietf-dots-signal-channel</dd>
Reference: RFC XXXX <dt>Maintained by IANA:</dt> <dd>N</dd>
]]></artwork> <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-dots-sig
</figure></t> nal-channel</dd>
<dt>Prefix:</dt> <dd>signal</dd>
<dt>Reference:</dt> <dd>RFC8782</dd>
</dl>
</li>
<li>
<dl newline="false" spacing="compact">
<dt>Name:</dt> <dd>iana-dots-signal-channel</dd>
<dt>Maintained by IANA:</dt> <dd>Y</dd>
<dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:iana-dots-si
gnal-channel</dd>
<dt>Prefix:</dt> <dd>iana-signal</dd>
<dt>Reference:</dt> <dd>RFC8782</dd>
</dl>
</li>
</ul>
<t>This document defines the initial version of the IANA-maintained <t>This document defines the initial version of the IANA-maintained
iana-dots-signal-channel YANG module. IANA is requested to add this iana-dots-signal-channel YANG module. IANA has added this
note:<list style="empty"> note:</t>
<t>Status, conflict status, conflict cause, and attack status <ul empty="true" spacing="normal">
<li>Status, conflict status, conflict cause, and attack status
values must not be directly added to the iana-dots-signal-channel values must not be directly added to the iana-dots-signal-channel
YANG module. They must instead be respectively added to the "DOTS YANG module. They must instead be respectively added to the "DOTS
Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause
Codes", and "DOTS Attack Status Codes" registries.</t> Codes", and "DOTS Attack Status Codes" registries.</li>
</list></t> </ul>
<t>When a 'status', 'conflict-status', 'conflict-cause', or <t>When a 'status', 'conflict-status', 'conflict-cause', or
'attack-status' value is respectively added to the "DOTS Status 'attack-status' value is respectively added to the "DOTS Status
Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", or Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", or
"DOTS Attack Status Codes" registry, a new "enum" statement must be "DOTS Attack Status Codes" registry, a new "enum" statement must be
added to the iana-dots-signal-channel YANG module. The following added to the iana-dots-signal-channel YANG module. The following
"enum" statement, and substatements thereof, should be defined:<list "enum" statement, and substatements thereof, should be defined:</t>
hangIndent="15" style="hanging"> <dl newline="false" spacing="normal" indent="15">
<t hangText="&quot;enum&quot;:">Replicates the label from the <dt>"enum":</dt>
registry.</t> <dd>Replicates the label from the registry.</dd>
<dt>"value":</dt>
<t hangText="&quot;value&quot;:">Contains the IANA-assigned value <dd>Contains the IANA-assigned value
corresponding to the 'status', 'conflict-status', corresponding to the 'status', 'conflict-status',
'conflict-cause', or 'attack-status'.</t> 'conflict-cause', or 'attack-status'.</dd>
<dt>"description":</dt>
<t hangText="&quot;description&quot;:">Replicates the description <dd>Replicates the description from the registry.</dd>
from the registry.</t> <dt>"reference":</dt>
<dd>Replicates the reference from
<t hangText="&quot;reference&quot;:">Replicates the reference from the registry and adds the title of the document.</dd>
the registry and adds the title of the document.</t> </dl>
</list></t>
<t>When the iana-dots-signal-channel YANG module is updated, a new <t>When the iana-dots-signal-channel YANG module is updated, a new
"revision" statement must be added in front of the existing revision "revision" statement must be added in front of the existing revision
statements.</t> statements.</t>
<t>IANA added this note to "DOTS Status Codes", "DOTS
<t>IANA is requested to add this note to "DOTS Status Codes", "DOTS
Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack
Status Codes" registries:</t> Status Codes" registries:</t>
<ul empty="true" spacing="normal">
<t><list style="empty"> <li>When this registry is modified, the YANG module
<t>When this registry is modified, the YANG module
iana-dots-signal-channel must be updated as defined in iana-dots-signal-channel must be updated as defined in
[RFCXXXX].</t> [RFC8782].</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>High-level DOTS security considerations are documented in <xref <t>High-level DOTS security considerations are documented in <xref target=
target="RFC8612"></xref> and <xref "RFC8612" format="default"/> and <xref target="I-D.ietf-dots-architecture" forma
target="I-D.ietf-dots-architecture"></xref>.</t> t="default"/>.</t>
<t>Authenticated encryption <bcp14>MUST</bcp14> be used for data confident
<t>Authenticated encryption MUST be used for data confidentiality and iality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) or Transport Layer Security Datagram Transport Layer Security (DTLS) or Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection, and the (TLS) with a cipher suite offering confidentiality protection, and the
guidance given in <xref target="RFC7525"></xref> MUST be followed to guidance given in <xref target="RFC7525" format="default"/> <bcp14>MUST</b cp14> be followed to
avoid attacks on (D)TLS. The (D)TLS protocol profile used for the DOTS avoid attacks on (D)TLS. The (D)TLS protocol profile used for the DOTS
signal channel is specified in <xref target="profile"></xref>.</t> signal channel is specified in <xref target="profile" format="default"/>.<
/t>
<t>If TCP is used between DOTS agents, an attacker may be able to inject <t>If TCP is used between DOTS agents, an attacker may be able to inject
RST packets, bogus application segments, etc., regardless of whether TLS RST packets, bogus application segments, etc., regardless of whether TLS
authentication is used. Because the application data is TLS protected, authentication is used. Because the application data is TLS protected,
this will not result in the application receiving bogus data, but it this will not result in the application receiving bogus data, but it
will constitute a DoS on the connection. This attack can be countered by will constitute a DoS on the connection. This attack can be countered by
using TCP-AO <xref target="RFC5925"></xref>. Although not widely using TCP Authentication Option (TCP-AO) <xref target="RFC5925" format="de fault"/>. Although not widely
adopted, if TCP-AO is used, then any bogus packets injected by an adopted, if TCP-AO is used, then any bogus packets injected by an
attacker will be rejected by the TCP-AO integrity check and therefore attacker will be rejected by the TCP-AO integrity check and therefore
will never reach the TLS layer.</t> will never reach the TLS layer.</t>
<t>
<t>An attack vector that can be achieved if the 'cuid' is guessable is a If the 'cuid' is guessable, a misbehaving DOTS client from within
misbehaving DOTS client from within the client's domain which uses the the client's domain can use the 'cuid' of another DOTS client of
'cuid' of another DOTS client of the domain to delete or alter active the domain to delete or alter active mitigations.
mitigations. For this attack vector to happen, the misbehaving client For this attack vector to happen, the misbehaving client
needs to pass the security validation checks by the DOTS server, and needs to pass the security validation checks by the DOTS server, and
eventually the checks of a client-domain DOTS gateway.</t> eventually the checks of a client-domain DOTS gateway.</t>
<t>A similar attack can be achieved by a compromised DOTS client that
<t>A similar attack can be achieved by a compromised DOTS client which
can sniff the TLS 1.2 handshake, use the client certificate to identify can sniff the TLS 1.2 handshake, use the client certificate to identify
the 'cuid' used by another DOTS client. This attack is not possible if the 'cuid' used by another DOTS client. This attack is not possible if
algorithms such as version 4 Universally Unique IDentifiers (UUIDs) in algorithms such as version 4 Universally Unique IDentifiers (UUIDs) in
Section 4.4 of <xref target="RFC4122"></xref> are used to generate the <xref target="RFC4122" section="4.4" sectionFormat="of" format="default"/> are used to generate the
'cuid' because such UUIDs are not a deterministic function of the client 'cuid' because such UUIDs are not a deterministic function of the client
certificate. Likewise, this attack is not possible with TLS 1.3 because certificate. Likewise, this attack is not possible with TLS 1.3 because
most of the TLS handshake is encrypted and the client certificate is not most of the TLS handshake is encrypted and the client certificate is not
visible to eavesdroppers.</t> visible to eavesdroppers.</t>
<t>A compromised DOTS client can collude with a DDoS attacker to send <t>A compromised DOTS client can collude with a DDoS attacker to send
mitigation request for a target resource, gets the mitigation efficacy mitigation request for a target resource, get the mitigation efficacy
from the DOTS server, and conveys the mitigation efficacy to the DDoS from the DOTS server, and convey the mitigation efficacy to the DDoS
attacker to possibly change the DDoS attack strategy. Obviously, attacker to possibly change the DDoS attack strategy. Obviously,
signaling an attack by the compromised DOTS client to the DOTS server signaling an attack by the compromised DOTS client to the DOTS server
will trigger attack mitigation. This attack can be prevented by will trigger attack mitigation. This attack can be prevented by
monitoring and auditing DOTS clients to detect misbehavior and to deter monitoring and auditing DOTS clients to detect misbehavior and to deter
misuse, and by only authorizing the DOTS client to request mitigation misuse, and by only authorizing the DOTS client to request mitigation
for specific target resources (e.g., an application server is authorized for specific target resources (e.g., an application server is authorized
to request mitigation for its IP addresses but a DDoS mitigator can to request mitigation for its IP addresses, but a DDoS mitigator can
request mitigation for any target resource in the network). Furthermore, request mitigation for any target resource in the network). Furthermore,
DOTS clients are typically co-located on network security services DOTS clients are typically co-located on network security services
(e.g., firewall) and a compromised security service potentially can do a (e.g., firewall), and a compromised security service potentially can do a
lot more damage to the network.</t> lot more damage to the network.</t>
<t>Rate-limiting DOTS requests, including those with new 'cuid' values, <t>Rate-limiting DOTS requests, including those with new 'cuid' values,
from the same DOTS client defends against DoS attacks that would result from the same DOTS client defend against DoS attacks that would result
in varying the 'cuid' to exhaust DOTS server resources. Rate-limit in varying the 'cuid' to exhaust DOTS server resources. Rate-limit
policies SHOULD be enforced on DOTS gateways (if deployed) and DOTS policies <bcp14>SHOULD</bcp14> be enforced on DOTS gateways (if deployed) and DOTS
servers.</t> servers.</t>
<t>In order to prevent leaking internal information outside a <t>In order to prevent leaking internal information outside a
client-domain, DOTS gateways located in the client-domain SHOULD NOT client's domain, DOTS gateways located in the client domain <bcp14>SHOULD NOT</bcp14>
reveal the identification information that pertains to internal DOTS reveal the identification information that pertains to internal DOTS
clients (e.g., source IP address, client's hostname) unless explicitly clients (e.g., source IP address, client's hostname) unless explicitly
configured to do so.</t> configured to do so.</t>
<t>DOTS servers <bcp14>MUST</bcp14> verify that requesting DOTS clients ar
<t>DOTS servers MUST verify that requesting DOTS clients are entitled to e 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 by a resources that belong to the DOTS client's domain <bcp14>MUST</bcp14> be a uthorized by a
DOTS server. The exact mechanism for the DOTS servers to validate that DOTS server. The exact mechanism for the DOTS servers to validate that
the target prefixes are within the scope of the DOTS client domain is the target prefixes are within the scope of the DOTS client domain is
deployment-specific.</t> deployment specific.</t>
<t>The presence of DOTS gateways may lead to infinite forwarding loops, <t>The presence of DOTS gateways may lead to infinite forwarding loops,
which is undesirable. To prevent and detect such loops, this document which is undesirable. To prevent and detect such loops, this document
uses the Hop-Limit Option.</t> uses the Hop-Limit option.</t>
<t>When FQDNs are used as targets, the DOTS server <bcp14>MUST</bcp14> rel
<t>When FQDNs are used as targets, the DOTS server MUST rely upon DNS y upon DNS
privacy enabling protocols (e.g., DNS over TLS <xref privacy-enabling protocols (e.g., DNS over TLS <xref target="RFC7858" form
target="RFC7858"></xref> or DoH <xref target="RFC8484"></xref>) to at="default"/> or DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/>
) to
prevent eavesdroppers from possibly identifying the target resources prevent eavesdroppers from possibly identifying the target resources
protected by the DDoS mitigation service, and means to ensure the target protected by the DDoS mitigation service to ensure the target
FQDN resolution is authentic (e.g., DNSSEC <xref FQDN resolution is authentic (e.g., DNSSEC <xref target="RFC4034" format="
target="RFC4034"></xref>).</t> default"/>).</t>
<t>CoAP-specific security considerations are discussed in
<t>CoAP-specific security considerations are discussed in Section 11 of <xref target="RFC7252" section="11" sectionFormat="of" format="default"/>,
<xref target="RFC7252"></xref>, while CBOR-related security while CBOR-related security
considerations are discussed in Section 8 of <xref considerations are discussed in <xref target="RFC7049" section="8" section
target="RFC7049"></xref>.</t> Format="of" format="default"/>.</t>
</section> </section>
</middle>
<back>
<displayreference target="I-D.ietf-dots-multihoming" to="DOTS-MH"/>
<displayreference target="I-D.ietf-core-yang-cbor" to="CORE-YANG-CBOR"/>
<displayreference target="I-D.ietf-core-comi" to="COMI"/>
<displayreference target="I-D.ietf-dots-use-cases" to="DOTS-USE-CASES"/>
<displayreference target="I-D.ietf-dots-architecture" to="DOTS-ARCH"/>
<displayreference target="I-D.ietf-tls-dtls13" to="DTLS"/>
<displayreference target="I-D.ietf-dots-server-discovery" to="DOTS-SERVER-DI
SC"/>
<displayreference target="I-D.boucadair-dots-earlydata" to="DOTS-EARLYDATA"/
>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7250.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7641.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8615.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4279.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6125.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7049.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7959.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4632.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7924.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8305.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8768.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4732.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7951.xml"/>
<reference anchor="IANA-MediaTypes" target="http://www.iana.org/assignme
nts/media-types">
<front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA-CoAP-Content-Formats" target="http://www.iana.or
g/assignments/core-parameters/core-parameters.xhtml#content-formats">
<front>
<title>CoAP Content-Formats</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA-CBOR-Tags" target="http://www.iana.org/assignmen
ts/cbor-tags/cbor-tags.xhtml">
<front>
<title>Concise Binary Object Representation (CBOR) Tags</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8499.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7858.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6052.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7030.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7452.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8489.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4987.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7413.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3022.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6146.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6724.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7589.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6888.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4787.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-dots-multihoming.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-core-yang-cbor.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-core-comi.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-dots-use-cases.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-dots-architecture.xml"/>
<reference anchor="RFC8783" target="https://www.rfc-editor.org/info/rfc8
783">
<front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification</title>
<author initials="M" surname="Boucadair" fullname="Mohamed
Boucadair" role="edi
tor">
<organization/>
</author>
<author initials="T" surname="Reddy.K" fullname="Tirumaleswar
Reddy.K" role="editor"
>
<organization/>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="RFC" value="8783"/>
<seriesInfo name="DOI" value="10.17487/RFC8783"/>
</reference>
<section anchor="contr" title="Contributors"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
<t>The following individuals have contributed to this document:<list I-D.ietf-tls-dtls13.xml"/>
style="symbols"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
<t>Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust</t> I-D.ietf-dots-server-discovery.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: FC.6887.xml"/>
mgeller@cisco.com</t> <reference anchor="I-D.boucadair-dots-earlydata">
<front>
<t>Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United <title>Using Early Data in DOTS</title>
States, Email: rgm@htt-consult.com</t> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
">
<t>Dan Wing, Email: dwing-ietf@fuggles.com</t> <organization/>
</list></t> </author>
<author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.
K">
<organization/>
</author>
<date month="January" day="29" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-boucadair-dots-earlydat
a-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-b
oucadair-dots-earlydata-00.txt"/>
</reference>
<reference anchor="IANA-Proto" target="http://www.iana.org/assignments/p
rotocol-numbers">
<front>
<title>Protocol Numbers</title>
<author>
<organization>IANA</organization>
</author>
<date year="2011"/>
</front>
</reference>
</references>
</references>
<section anchor="motiv" numbered="true" toc="default">
<name>CUID Generation</name>
<t>The document recommends the use of SPKI to generate the 'cuid'. This
design choice is motivated by the following reasons:</t>
<ul spacing="normal">
<li>SPKI is globally unique.</li>
<li>It is deterministic.</li>
<li>It allows the avoidance of extra cycles that may be induced by 'cuid
'
collision.</li>
<li>DOTS clients do not need to store the 'cuid' in a persistent
storage.</li>
<li>It allows the detection of compromised DOTS clients that do not adhe
re
to the 'cuid' generation algorithm.</li>
</ul>
</section> </section>
<section anchor="ack" numbered="false" toc="default">
<section anchor="ack" title="Acknowledgements"> <name>Acknowledgements</name>
<t>Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael <t>Thanks to <contact fullname="Christian Jacquenet"/>, <contact fullname=
Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, "Roland Dobbins"/>,
Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien <contact fullname="Roman Danyliw"/>, <contact fullname="Michael Richardson
Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion and "/>,
<contact fullname="Ehud Doron"/>, <contact fullname="Kaname Nishizuka"/>,
<contact fullname="Dave Dolson"/>, <contact fullname="Liang Xia"/>,
<contact fullname="Gilbert Clark"/>, <contact fullname="Xialiang Frank"/>,
<contact fullname="Jim Schaad"/>, <contact fullname="Klaus Hartke"/>,
<contact fullname="Nesredien Suleiman"/>, <contact fullname="Stephen Farre
ll"/>, and
<contact fullname="Yoshifumi Nishida"/> for the discussion and
comments.</t> comments.</t>
<t>The authors would like to give special thanks to <contact fullname="Kan
<t>The authors would like to give special thanks to Kaname Nishizuka and ame Nishizuka"/> and
Jon Shallow for their efforts in implementing the protocol and <contact fullname="Jon Shallow"/> for their efforts in implementing the pr
otocol and
performing interop testing at IETF Hackathons.</t> performing interop testing at IETF Hackathons.</t>
<t>Thanks to the core WG for the recommendations on Hop-Limit and <t>Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling.</t> redirect signaling.</t>
<t>Special thanks to <contact fullname="Benjamin Kaduk"/> for the detailed
<t>Special thanks to Benjamin Kaduk for the detailed AD review.</t> AD review.</t>
<t>Thanks to <contact fullname="Alexey Melnikov"/>, <contact fullname="Ada
<t>Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja m Roach"/>,
K&uuml;hlewind, and Alissa Cooper for the review.</t> <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"
/>, and
<t>Thanks to Carsten Bormann for his review of the DOTS heartbeat <contact fullname="Alissa Cooper"/> for the review.</t>
<t>Thanks to <contact fullname="Carsten Bormann"/> for his review of the D
OTS heartbeat
mechanism.</t> mechanism.</t>
</section> </section>
</middle> <section anchor="contr" numbered="false" toc="default">
<name>Contributors</name>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include="reference.RFC.7525"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.7252"?>
<?rfc include="reference.RFC.7250"?>
<?rfc include="reference.RFC.7641"?>
<?rfc include="reference.RFC.8615"?>
<?rfc include="reference.RFC.4279"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include='reference.RFC.6991'?>
<?rfc include='reference.RFC.5246'?>
<?rfc include="reference.RFC.6125"?>
<?rfc include='reference.RFC.3688'?>
<?rfc include="reference.RFC.7950"?>
<?rfc include='reference.RFC.8126'?>
<?rfc include='reference.RFC.6066'?>
<?rfc include="reference.RFC.8323"?>
<?rfc include="reference.RFC.8085"?>
<?rfc include="reference.RFC.7049"?>
<?rfc include="reference.RFC.8446"?>
<?rfc include="reference.RFC.7959"?>
<?rfc include="reference.RFC.4632"?>
<?rfc include="reference.RFC.7918"?>
<?rfc include="reference.RFC.7924"?>
<?rfc include='reference.RFC.4648'?>
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.8200'?>
<?rfc include='reference.RFC.1122'?>
<?rfc include='reference.RFC.8305'?>
<?rfc include='reference.RFC.0791'?>
<?rfc include='reference.I-D.ietf-core-hop-limit'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4732"?>
<?rfc include='reference.RFC.7951'?>
<reference anchor="IANA.MediaTypes"
target="http://www.iana.org/assignments/media-types">
<front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
<reference anchor="IANA.CoAP.Content-Formats"
target="http://www.iana.org/assignments/core-parameters/core-pa
rameters.xhtml#content-formats">
<front>
<title>CoAP Content-Formats</title>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
<reference anchor="IANA.CBOR.Tags"
target="http://www.iana.org/assignments/cbor-tags/cbor-tags.xht
ml">
<front>
<title>Concise Binary Object Representation (CBOR) Tags</title>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
<?rfc include='reference.RFC.8499'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.7858'?>
<?rfc include='reference.RFC.8484'?>
<?rfc include="reference.RFC.6234"?>
<?rfc include='reference.RFC.4122'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.7030'?>
<?rfc include='reference.RFC.7452'?>
<?rfc include="reference.RFC.5925"?>
<?rfc include='reference.RFC.5389'?>
<?rfc include='reference.RFC.4987'?>
<?rfc include="reference.RFC.7413"?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.6724'?>
<?rfc include="reference.RFC.7589"?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.RFC.4787'?>
<?rfc include='reference.RFC.4340'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.8340'?>
<?rfc include='reference.RFC.6838'?>
<?rfc include='reference.I-D.ietf-dots-multihoming'?>
<?rfc include="reference.I-D.ietf-core-yang-cbor"?>
<?rfc include="reference.I-D.ietf-core-comi"?>
<?rfc include="reference.RFC.8612"?>
<?rfc include="reference.I-D.ietf-dots-use-cases"?>
<?rfc include="reference.I-D.ietf-dots-architecture"?>
<?rfc include="reference.I-D.ietf-dots-data-channel" ?>
<?rfc include="reference.I-D.ietf-tls-dtls13"?>
<?rfc include='reference.I-D.ietf-dots-server-discovery'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.I-D.boucadair-dots-earlydata'?>
<reference anchor="proto_numbers"
target="http://www.iana.org/assignments/protocol-numbers">
<front>
<title>IANA, "Protocol Numbers"</title>
<author>
<organization></organization>
</author>
<date year="2011" />
</front>
</reference>
</references>
<section anchor="motiv" title="CUID Generation"> <t>The following individuals have contributed to this
<t>The document recommends the use of SPKI to generate the 'cuid'. This document:</t>
design choice is motivated by the following reasons:<list
style="symbols">
<t>SPKI is globally unique.</t>
<t>It is deterministic.</t> <contact fullname="Jon Shallow" >
<organization>NCC Group</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>jon.shallow@nccgroup.trust</email>
</address>
</contact>
<t>It allows to avoid extra cycles that may be induced by 'cuid' <contact fullname="Mike Geller" >
collision.</t> <organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region>FL</region><code>33309</code>
<country>United States of America</country>
</postal>
<email>mgeller@cisco.com</email>
</address>
</contact>
<t>DOTS clients do not need to store the 'cuid' in a persistent <contact fullname="Robert Moskowitz" >
storage.</t> <organization>HTT Consulting</organization>
<address>
<postal>
<street></street>
<city>Oak Park</city>
<region>MI</region><code>42837</code>
<country>United States of America</country>
</postal>
<email>rgm@htt-consult.com</email>
</address>
</contact>
<t>It allows to detect compromised DOTS clients that do not adhere <contact fullname="Dan Wing" >
to the 'cuid' generation algorithm.</t> <organization></organization>
</list></t> <address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>dwing-ietf@fuggles.com</email>
</address>
</contact>
<t></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 687 change blocks. 
2704 lines changed or deleted 3674 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/