rfc9132xml2.original.xml   rfc9132.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 tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dots-rfc8782
<?rfc tocdepth="4"?> -bis-08" number="9132" ipr="trust200902" obsoletes="8782" updates="" submissionT
<?rfc tocindent="yes"?> ype="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDe
<?rfc symrefs="yes"?> pth="4" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <!-- xml2rfc v2v3 conversion 3.8.0 -->
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dots-rfc8782-bis-08" ipr="trust200902"
obsoletes="8782">
<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="9132"/>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
surname="Boucadair"> ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<region/>
<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="Jon Shallow" initials="J." surname="Shallow"> <author fullname="Jon Shallow" initials="J." surname="Shallow">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>supjps-ietf@jpshallow.com</email> <email>supjps-ietf@jpshallow.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K"> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization>Akamai</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>
<phone/>
<phone></phone>
<facsimile></facsimile>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
<uri/>
<uri></uri>
</address> </address>
</author> </author>
<date month="September" year="2021" />
<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 Distributed Denial-of-Service Open Threat <t>This document specifies the Distributed Denial-of-Service Open Threat
Signaling (DOTS) signal channel, a protocol for signaling the need for Signaling (DOTS) signal channel, a protocol for signaling the need for
protection against Distributed Denial-of-Service (DDoS) attacks to a protection against Distributed Denial-of-Service (DDoS) attacks to a
server capable of enabling network traffic mitigation on behalf of the server capable of enabling network traffic mitigation on behalf of the
requesting client.</t> 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>
<t>This document obsoletes RFC 8782.</t> <t>This document obsoletes RFC 8782.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>A Distributed Denial-of-Service (DDoS) attack is a distributed <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>Network applications have finite resources, like CPU cycles, the
<t>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 resources number of simultaneous connections they can handle, the resources
assigned to 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. Stateful firewalls can also be attacked by sending
traffic that causes the firewall to maintain an excessive number of traffic that causes the firewall to maintain an excessive number of
states that may jeopardize the firewall's operation overall, in addition states that may jeopardize the firewall's operation overall, in addition
to likely performance impacts. The firewall then runs out of memory, and to likely performance impacts. The firewall then runs out of memory, and
it can no longer instantiate the states required to process legitimate it can no longer instantiate the states required to process legitimate
flows. Other possible DDoS attacks are discussed in <xref flows. Other possible DDoS attacks are discussed in <xref target="RFC4732"
target="RFC4732"></xref>.</t> 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" sectionFormat="of" section=
target="RFC8612"></xref>.</t> "2.4"/>.</t>
<t>In typical deployments, the DOTS client belongs to a different <t>In typical deployments, the DOTS client belongs to a different
administrative domain than the DOTS server. For example, the DOTS client administrative domain than the DOTS server. For example, the DOTS client
is embedded in a firewall protected services owned and operated by a is embedded in a firewall-protected service owned and operated by a
customer, while the DOTS server is owned and operated by a different customer, while the DOTS server is owned and operated by a different
administrative entity (service provider, typically) providing DDoS administrative entity (service provider, typically) providing DDoS
mitigation services. The latter might or might not provide connectivity mitigation services. The latter might or might not provide connectivity
services to the network hosting the DOTS client.</t> services to the network hosting the DOTS client.</t>
<t>The DOTS server may or may not be co-located with the DOTS mitigator. <t>The DOTS server may or may not be co-located with the DOTS mitigator.
In typical deployments, the DOTS server belongs to the same In typical deployments, the DOTS server belongs to the same
administrative domain as the mitigator. The DOTS client can communicate administrative domain as the mitigator. The DOTS client can communicate
directly with a DOTS server or indirectly via a DOTS gateway.</t> directly with a DOTS server or indirectly via a DOTS gateway.</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 Local Area Network (LAN), while a DOTS gateway is embedded in the
CPE (Customer Premises Equipment).</t> Customer Premises Equipment (CPE).</t>
<figure anchor="fig1">
<t><figure align="left" anchor="fig1" title="Sample DOTS Deployment (1)"> <name>Sample DOTS Deployment (1)</name>
<artwork align="left"><![CDATA[ Network <artwork align="left" name="" type="" alt=""><![CDATA[
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> ]]></artwork>
</figure></t> </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[ Network <artwork align="center" name="" type="" alt=""><![CDATA[
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></t> </figure>
<t>This document adheres to the DOTS architecture <xref target="RFC8811" f
<t>This document adheres to the DOTS architecture <xref ormat="default"/>. The requirements for the DOTS signal channel
target="RFC8811"></xref>. The requirements for DOTS signal channel protocol are documented in <xref target="RFC8612" format="default"/>. This
protocol are documented in <xref target="RFC8612"></xref>. This document document
satisfies all the use cases discussed in <xref satisfies all the use cases discussed in <xref target="RFC8903" format="de
target="RFC8903"></xref>.</t> fault"/>.</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="RFC8783"></xref> that defines a configuration and a bulk data mat="default"/> that defines a configuration and a bulk data
exchange mechanism supporting the DOTS signal channel.</t> exchange mechanism supporting the DOTS signal channel.</t>
<t>Backward compatibility (including upgrade) considerations are <t>Backward compatibility (including upgrade) considerations are
discussed in <xref target="back"></xref>.</t> discussed in <xref target="back" format="default"/>.</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>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and 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"/> and <xref target="RFC7252" format="default"/>.</t>
target="RFC8612"></xref> and <xref target="RFC7252"></xref>.</t> <t>The meaning of the symbols in YANG tree diagrams are defined in <xref t
arget="RFC8340" format="default"/> and <xref target="RFC8791" format="default"/>
<t>The meaning of the symbols in YANG tree diagrams are defined in <xref .</t>
target="RFC8340"></xref> and <xref target="RFC8791"></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) make it a good candidate upon which resources, and support for (D)TLS) make it a good candidate upon which
to build the DOTS signaling mechanism.</t> to 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 behaves as a CoAP client and a DOTS server behaves as CoAP client behaves as a CoAP client and a DOTS server behaves as CoAP
server. Nevertheless, a DOTS client (or server) behaves as a CoAP server server. Nevertheless, a DOTS client (or server) behaves as a CoAP server
(or client) for specific operations such as DOTS heartbeat operations (or client) for specific operations, such as DOTS heartbeat operations
(<xref target="hb"></xref>).</t> (<xref target="hb" format="default"/>).</t>
<t>The DOTS signal channel is layered on existing standards (see <xref tar
<t>The DOTS signal channel is layered on existing standards (see <xref get="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 a mutual agreement <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 to use a specific port number, such as by explicit configuration or
dynamic discovery <xref target="RFC8973"></xref>. Absent such mutual dynamic discovery <xref target="RFC8973" format="default"/>. Absent such m
agreement, the DOTS signal channel MUST run over port number 4646 as utual
defined in <xref target="port"></xref>, for both UDP and TCP (that is, agreement, the DOTS signal channel <bcp14>MUST</bcp14> run over
port number 4646, as
defined in <xref target="port" format="default"/>, for both UDP and TCP (t
hat is,
the DOTS server listens on port number 4646). In order to use a distinct the DOTS server listens on port number 4646). In order to use a distinct
port number (as opposed to 4646), DOTS clients and servers SHOULD port number (as opposed to 4646), DOTS clients and servers <bcp14>SHOULD</ bcp14>
support a configurable parameter to supply the port number to support a configurable parameter to supply the port number to
use.<figure> use.</t>
<artwork><![CDATA[ | Note: The rationale for not using the defau <aside>
lt 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 ((D)TLS CoAP) is to avoid the discovery of services and
| resources discussed in [RFC7252] and allow for differentiated resources discussed in <xref target="RFC7252" format="default"/>
| behaviors in environments where both a DOTS gateway and an and allow for differentiated
| Internet of Things (IoT) gateway (e.g., Figure 3 of [RFC7452]) behaviors in environments where both a DOTS gateway and an
| are co-located. Internet of Things (IoT) gateway (e.g., Figure 3 of <xref target="RFC745
| 2"
| Particularly, the use of a default port number is meant to format="default"/>) are co-located.</t>
| simplify DOTS deployment in scenarios where no explicit IP
| address configuration is required. For example, the use of the
| default router as the DOTS server aims to ease DOTS deployment
| within LANs (in which CPEs embed a DOTS gateway as illustrated
| in Figures 1 and 2) without requiring a sophisticated discovery
| method and configuration tasks within the LAN. It is also
| possible to use anycast addresses for DOTS servers to simplify
| DOTS client configuration, including service discovery. In
| such an anycast-based scenario, a DOTS client initiating a DOTS
| 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 client following the procedure discussed in
| Section 4.6 or (2) relayed to a unicast DOTS server.]]></artwork>
</figure></t>
<t>The signal channel uses the "coaps" URI scheme defined in Section 6 <t>Particularly, the use of a default port number is meant to
of <xref target="RFC7252"></xref> and the "coaps+tcp" URI scheme defined simplify DOTS deployment in scenarios where no explicit IP
in Section 8.2 of <xref target="RFC8323"></xref> to identify DOTS server address configuration is required. For example, the use of the
default router as the DOTS server aims to ease DOTS deployment
within LANs (in which CPEs embed a DOTS gateway, as illustrated
in Figures 1 and 2) without requiring a sophisticated discovery
method and configuration tasks within the LAN. It is also
possible to use anycast addresses for DOTS servers to simplify
DOTS client configuration, including service discovery. In
such an anycast-based scenario, a DOTS client initiating a DOTS
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 client following the procedure discussed in
<xref target="redirect" format="default"/> or (2) relayed to a unicast D
OTS server.</t>
</aside>
<t>The signal channel uses the "coaps" URI scheme defined in <xref target=
"RFC7252"
sectionFormat="of" section="6"/> and the "coaps+tcp" URI scheme defined
in <xref target="RFC8323" sectionFormat="of" section="8.2"/> to identify D
OTS server
resources that are accessible using CoAP over UDP secured with DTLS and resources that are accessible using CoAP over UDP secured with DTLS and
CoAP over TCP secured with TLS, respectively.</t> 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 to or during an attack. The DOTS signal channel is initiated by prior to or during an attack. The DOTS signal channel is initiated by
the DOTS client. The DOTS client can then negotiate, configure, and the DOTS client. The DOTS client can then negotiate, configure, and
retrieve the DOTS signal channel session behavior with its DOTS peer retrieve the DOTS signal channel session behavior with its DOTS peer
(<xref target="sigconfig"></xref>). Once the signal channel is (<xref target="sigconfig" format="default"/>). Once the signal channel is
established, the DOTS agents may periodically send heartbeats to keep established, the DOTS agents may periodically send heartbeats to keep
the channel active (<xref target="hb"></xref>). At any time, the DOTS the channel active (<xref target="hb" format="default"/>). At any time, th
client may send a mitigation request message (<xref e DOTS
target="m_req"></xref>) to a DOTS server over the active signal channel. client may send a mitigation request message (<xref target="m_req" format=
"default"/>) to a DOTS server over the active signal channel.
While mitigation is active (because of the higher likelihood of packet While mitigation is active (because of the higher likelihood of packet
loss during a DDoS attack), the DOTS server periodically sends status loss during a DDoS attack), the DOTS server periodically sends status
messages to the client, including basic mitigation feedback details. messages to the client, including basic mitigation feedback details.
Mitigation remains active until the DOTS client explicitly terminates Mitigation remains active until the DOTS client explicitly terminates
mitigation or the mitigation lifetime expires. Also, the DOTS server may mitigation or the mitigation lifetime expires. Also, the DOTS server may
rely on the signal channel session loss to trigger mitigation for rely on the signal channel session loss to trigger mitigation for
preconfigured mitigation requests (if any).</t> preconfigured mitigation requests (if any).</t>
<t>DOTS signaling can use DTLS over UDP and TLS over TCP. Likewise, DOTS <t>DOTS signaling can use DTLS over UDP and TLS over TCP. Likewise, DOTS
requests may be sent using IPv4 or IPv6 transfer capabilities. A Happy requests may be sent using IPv4 or IPv6 transfer capabilities. A Happy
Eyeballs procedure for the DOTS signal channel is specified in <xref Eyeballs procedure for the DOTS signal channel is specified in <xref targe
target="HE"></xref>.</t> t="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 the resources it creates. In
particular, a DOTS client cannot retrieve data related to mitigation particular, a DOTS client cannot 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="RFC8949"></xref>, a Binary Object Representation (CBOR) <xref target="RFC8949" 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 that convey request parameters and response information such as messages that convey request parameters and response information, such as
errors. In order to allow the reusing of data models across protocols, errors. In order to allow the reusing of data models across protocols,
<xref target="RFC7951"></xref> specifies the JavaScript Object Notation <xref target="RFC7951" format="default"/> specifies the JavaScript Object Notation
(JSON) encoding of YANG-modeled data. A similar effort for CBOR is (JSON) encoding of YANG-modeled data. A similar effort for CBOR is
defined in <xref target="I-D.ietf-core-yang-cbor"></xref>.</t> defined in <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
in the payload of the DOTS signal channel are mapped to CBOR types as rameters
specified in <xref target="mapping">Table 5</xref>.</t> in the payload of the DOTS signal channel are mapped to CBOR types, as
specified in <xref target="table5" format="default"/> (<xref target="mappi
ng"
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" sectionFormat="of" se
target="RFC7252"></xref>. Refer to <xref target="mtu"></xref> for more ction="4.6"/>.
Refer to <xref target="mtu" format="default"/> for 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" sectionFormat="of" section="5.5.2"/>). The diagnos
tic
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 single <t>In deployments where multiple DOTS clients are enabled in a single
network and administrative domain (called, DOTS client domain), the DOTS network and administrative domain (called DOTS client domain), the DOTS
server may detect conflicting mitigation requests from these clients. server may detect conflicting mitigation requests from these clients.
This document does not aim to specify a comprehensive list of conditions This document does not aim to specify a comprehensive list of conditions
under which a DOTS server will characterize two mitigation requests from under which a DOTS server will characterize two mitigation requests from
distinct DOTS clients as conflicting, nor does it recommend a DOTS distinct DOTS clients as conflicting, nor does it recommend a DOTS
server behavior for processing conflicting mitigation requests. Those server behavior for processing conflicting mitigation requests. Those
considerations are implementation and deployment specific. Nevertheless, considerations are implementation and deployment specific. Nevertheless,
this document specifies the mechanisms to notify DOTS clients when this document specifies the mechanisms to notify DOTS clients when
conflicts occur, including the conflict cause (<xref conflicts occur, including the conflict cause (<xref target="pro-mit-req"
target="m_req"></xref>).</t> 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
NAT64 <xref target="RFC6146"></xref>, NPTv6 <xref target="RFC6888" format="default"/>,
target="RFC6296"></xref>) are enabled between the client's network and NAT64 <xref target="RFC6146" format="default"/>, NPTv6 <xref target="RFC62
96" format="default"/>) are
enabled between the client's network and
the DOTS server, any DOTS signal channel messages forwarded to a DOTS the DOTS server, any DOTS signal channel messages forwarded to a DOTS
server MUST NOT include internal IP addresses/prefixes and/or port server <bcp14>MUST NOT</bcp14> include internal IP addresses/prefixes and/ or port
numbers; instead, external addresses/prefixes and/or port numbers as numbers; instead, external addresses/prefixes and/or port numbers as
assigned by the translator MUST be used. This document does not make any assigned by the translator <bcp14>MUST</bcp14> be used. This document does not make any
recommendations 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 hangText="*">Port Control Protocol (PCP) <xref <ul spacing="normal">
target="RFC6887"></xref> or Session Traversal Utilities for NAT <li>Port Control Protocol (PCP) <xref target="RFC6887"
(STUN) <xref target="RFC8489"></xref> may be used by the client to format="default"/> or Session Traversal Utilities for NAT
(STUN) <xref target="RFC8489" format="default"/> may be used by the cl
ient to
retrieve the external addresses/prefixes and/or port numbers. retrieve the external addresses/prefixes and/or port numbers.
Information retrieved by means of PCP or STUN will be used to feed Information retrieved by means of PCP or STUN will be used to feed
the DOTS signal channel messages that will be sent to a DOTS the DOTS signal channel messages that will be sent to a DOTS
server.</t> 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.</t> translator's binding table.</li>
</list></t> </ul>
<section anchor="back" numbered="true" toc="default">
<section anchor="back" title="Backward Compatibility Considerations"> <name>Backward Compatibility Considerations</name>
<t>The main changes to <xref target="RFC8782"></xref> are listed in <t>The main changes to <xref target="RFC8782" format="default"/> are lis
<xref target="changes"></xref>. These modifications are made with the ted in
<xref target="changes" format="default"/>. These modifications are made
with the
constraint to avoid changes to the mapping table defined in Table 5 of constraint to avoid changes to the mapping table defined in Table 5 of
<xref target="RFC8782"></xref> (see also <xref <xref target="RFC8782" format="default"/> (see also <xref target="mappin
target="mapping"></xref> of the present document). </t> g" format="default"/> of the present document). </t>
<t>For both legacy <xref target="RFC8782" format="default"/> and impleme
<t>For both legacy <xref target="RFC8782"></xref> and implementations ntations
that follow the present specification, a DOTS signal channel attribute that follow the present specification, a DOTS signal channel attribute
will thus have the same CBOR key value and CBOR major type. The only will thus have the same CBOR key value and CBOR major type. The only
upgrade that is required to <xref target="RFC8782"></xref> upgrade that is required to <xref target="RFC8782" format="default"/>
implementations is to handle the CBOR key value range "128-255" as implementations is to handle the CBOR key value range "128-255" as
comprehension-optional instead of comprehension-required. Note that comprehension-optional instead of comprehension-required. Note that
this range is anticipated to be used by the DOTS telemetry <xref this range is anticipated to be used by the DOTS telemetry <xref target=
target="I-D.ietf-dots-telemetry"></xref> in which the following means "I-D.ietf-dots-telemetry" format="default"/> in which the following means
are used to prevent message processing failure of a DOTS signal are used to prevent message processing failure of a DOTS signal
channel message enriched with telemetry data: (1) DOTS agents use channel message enriched with telemetry data: (1) DOTS agents use
dedicated (new) path suffixes (Section 5 of <xref dedicated (new) path suffixes (<xref target="I-D.ietf-dots-telemetry" se
target="I-D.ietf-dots-telemetry"></xref>) and (2) a DOTS server won't ctionFormat="of" section="5"/>) and (2) a DOTS server won't
include telemetry attributes in its responses unless it is explicitly include telemetry attributes in its responses unless it is explicitly
told to do so by a DOTS client (Section 6.1.2 of <xref told to do so by a DOTS client (<xref target="I-D.ietf-dots-telemetry" s
target="I-D.ietf-dots-telemetry"></xref>).</t> ectionFormat="of" section="6.1.2"/>).</t>
<t>Future DOTS extensions that request a CBOR value in the range <t>Future DOTS extensions that request a CBOR value in the range
"128-255" MUST support means similar to the aforementioned DOTS "128-255" <bcp14>MUST</bcp14> support means similar to the aforementione d DOTS
telemetry ones.</t> telemetry ones.</t>
</section> </section>
</section> </section>
<section anchor="sig" numbered="true" toc="default">
<section anchor="sig" <name>DOTS Signal Channel: Messages &amp; Behaviors</name>
title="DOTS Signal Channel: Messages &amp; Behaviors"> <section anchor="discover" numbered="true" toc="default">
<section anchor="discover" title="DOTS Server(s) Discovery"> <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="RFC8973"></xref>). The description of such means is DHCP <xref target="RFC8973" format="default"/>). The description of such
means is
out of scope of this document.</t> 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 the scope of this document to specify the
behavior to be followed by a DOTS client in order to send DOTS behavior to be followed by a DOTS client in order to send DOTS
requests when multiple DOTS servers are provisioned (e.g., contact all requests when multiple DOTS servers are provisioned (e.g., contact all
DOTS servers, select one DOTS server among the list). Such behavior is DOTS servers, select one DOTS server among the list). Such behavior is
specified in other documents (e.g., <xref specified in other documents (e.g., <xref target="I-D.ietf-dots-multihom
target="I-D.ietf-dots-multihoming"></xref>).</t> ing" format="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
"/.well-known/" as defined in <xref target="RFC8615" format="default"/>
and the
registered name of "dots". Each DOTS operation is denoted by a path registered name of "dots". Each DOTS operation is denoted by a path
suffix that indicates the intended operation. The operation path suffix that indicates the intended operation. The operation path
(Table 1) is appended to the path prefix to form the URI used with a (<xref target="table1" format="default"/>) is appended to the path prefi
x to form the
URI used with a
CoAP request to perform the desired DOTS operation.</t> CoAP request to perform the desired DOTS operation.</t>
<table anchor="table1" align="center">
<figure> <name>Operations and Corresponding URIs</name>
<artwork align="center"><![CDATA[+-----------------------+------------ <thead>
----+-------------+ <tr>
| Operation | Operation Path | Details | <th>Operation</th>
+=======================+================+=============+ <th>Operation Path</th>
| Mitigation | /mitigate | Section 4.4 | <th>Details</th>
+-----------------------+----------------+-------------+ </tr>
| Session configuration | /config | Section 4.5 | </thead>
+-----------------------+----------------+-------------+ <tbody>
| Heartbeat | /hb | Section 4.7 | <tr>
+-----------------------+----------------+-------------+ <td>Mitigation</td>
<td>/mitigate</td>
Table 1: Operations and Corresponding URIs]]></artwork> <td><xref target="m_req" format="default"/></td>
</figure> </tr>
<tr>
<t></t> <td>Session configuration</td>
<td>/config</td>
<td><xref target="sigconfig" format="default"/></td>
</tr>
<tr>
<td>Heartbeat</td>
<td>/hb</td>
<td><xref target="hb" format="default"/></td>
</tr>
</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 a procedure is needed to avoid experiencing long connection
delays. For example, if an IPv4 path to a DOTS server is functional, delays. For example, if an IPv4 path to a DOTS server is functional,
but the DOTS server's IPv6 path is nonfunctional, a dual-stack DOTS but the DOTS server's IPv6 path is nonfunctional, a dual-stack DOTS
client may experience a significant connection delay compared to an client may experience a significant connection delay compared to an
IPv4-only DOTS client in the same network conditions. The other IPv4-only DOTS client in the same network conditions. The other
problem is that if a middlebox between the DOTS client and DOTS server problem is that if a middlebox between the DOTS client and DOTS server
is configured to block UDP traffic, the DOTS client will fail to is configured to block UDP traffic, the DOTS client will fail to
establish a DTLS association with the DOTS server; consequently, it establish a DTLS association with the DOTS server; consequently, it
will have to fall back to TLS over TCP, thereby incurring significant will have to fall back to TLS over TCP, thereby incurring significant
connection delays.</t> connection delays.</t>
skipping to change at line 527 skipping to change at line 446
<t>Such a procedure is needed to avoid experiencing long connection <t>Such a procedure is needed to avoid experiencing long connection
delays. For example, if an IPv4 path to a DOTS server is functional, delays. For example, if an IPv4 path to a DOTS server is functional,
but the DOTS server's IPv6 path is nonfunctional, a dual-stack DOTS but the DOTS server's IPv6 path is nonfunctional, a dual-stack DOTS
client may experience a significant connection delay compared to an client may experience a significant connection delay compared to an
IPv4-only DOTS client in the same network conditions. The other IPv4-only DOTS client in the same network conditions. The other
problem is that if a middlebox between the DOTS client and DOTS server problem is that if a middlebox between the DOTS client and DOTS server
is configured to block UDP traffic, the DOTS client will fail to is configured to block UDP traffic, the DOTS client will fail to
establish a DTLS association with the DOTS server; consequently, it establish a DTLS association with the DOTS server; consequently, it
will have to fall back to TLS over TCP, thereby incurring significant will have to fall back to TLS over TCP, thereby incurring significant
connection delays.</t> 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 it tries both DTLS over UDP and TLS over TCP following a DOTS 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 Happy Eyeballs approach. To some extent, this approach is similar to
the Happy Eyeballs mechanism defined in <xref the Happy Eyeballs mechanism defined in <xref target="RFC8305" format="d
target="RFC8305"></xref>. The connection attempts are performed by the efault"/>. The connection attempts are performed by the
DOTS client when it initializes or, in general, when it has to select DOTS client when it initializes or, in general, when it has to select
an address family and transport to contact its DOTS server. The an address family and transport to contact its DOTS server. The
results of the Happy Eyeballs procedure are used by the DOTS client results of the Happy Eyeballs procedure are used by the DOTS client
for sending its subsequent messages to the DOTS server. The for sending its subsequent messages to the DOTS server. The
differences in behavior with respect to the Happy Eyeballs mechanism differences in behavior with respect to the Happy Eyeballs mechanism
<xref target="RFC8305"></xref> are listed below:</t> <xref target="RFC8305" format="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 family and transport protocol (most preferred first) is the
following: UDP over IPv6, UDP over IPv4, TCP over IPv6, and following: UDP over IPv6, UDP over IPv4, TCP over IPv6, and
finally TCP over IPv4. This order adheres to the address finally TCP over IPv4. This order adheres to the address
preference order specified in <xref target="RFC6724"></xref> and preference order specified in <xref target="RFC6724" format="default "/> and
the DOTS signal channel preference that promotes the use of UDP the DOTS signal channel preference that promotes the use of UDP
over TCP (to avoid TCP's head of line blocking).</t> over TCP (to avoid TCP's head of line blocking).</li>
<li>After successfully establishing a connection, the DOTS client
<t>After successfully establishing a connection, the DOTS client <bcp14>MUST</bcp14> cache information regarding the outcome of each
MUST cache information regarding the outcome of each connection connection
attempt for a specific time period; it uses that information to attempt for a specific time period; it uses that information to
avoid thrashing the network with subsequent attempts. The cached avoid thrashing the network with subsequent attempts. The cached
information is flushed when its age exceeds a specific time period information is flushed when its age exceeds a specific time period
on the order of few minutes (e.g., 10 min). Typically, if the DOTS on the order of few minutes (e.g., 10 min). Typically, if the DOTS
client has to reestablish the connection with the same DOTS server client has to reestablish the connection with the same DOTS server
within a few seconds after the Happy Eyeballs mechanism is within a few seconds after the Happy Eyeballs mechanism is
completed, caching avoids thrashing the network especially in the completed, caching avoids thrashing the network especially in the
presence of DDoS attack traffic.</t> presence of DDoS attack traffic.</li>
<li>If a DOTS signal channel session is established with TLS (but
<t>If a 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 become available from the DOTS server; this is so the DOTS UDP become available from the DOTS server; this is so the DOTS
client can migrate the DOTS signal channel from TCP to UDP. Such client can migrate the DOTS signal channel from TCP to UDP. Such
probing SHOULD NOT be done more frequently than every 24 hours and probing <bcp14>SHOULD NOT</bcp14> be done more frequently than every
MUST NOT be done more frequently than every 5 minutes.</t> 24 hours and
</list></t> <bcp14>MUST NOT</bcp14> be done more frequently than every 5 minutes
.</li>
<t><!-- </ul>
use a "Connection Attempt Delay" <xref target="RFC8305"></xref> set to <t>When connection attempts are made during an attack, the DOTS client
<bcp14>SHOULD</bcp14>
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 cli
<t>In <xref target="fig_happy_eyeballs"></xref>, the DOTS client ent
proceeds with the connection attempts following the rules in <xref proceeds with the connection attempts following the rules in <xref targe
target="RFC8305"></xref>. In this example, it is assumed that the IPv6 t="RFC8305" format="default"/>. In this example, it is assumed that the IPv6
path is broken and UDP traffic is dropped by a middlebox, but this has path is broken and UDP traffic is dropped by a middlebox, but this has
little impact on the DOTS client because there is not a long delay 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 reuse 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 retrieve, or withdraw the status of mitigation requests:</t>
hangIndent="8" style="hanging"> <dl newline="false" spacing="normal" indent="9">
<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>
<t hangText="GET:">DOTS clients may use the GET method to retrieve <dt>GET:</dt>
the list of its mitigations maintained by a DOTS server (<xref <dd>DOTS clients may use the GET method to retrieve
target="get"></xref>) or to receive asynchronous DOTS server the list of its mitigations maintained by a DOTS server (<xref targe
status messages (<xref target="obs"></xref>).</t> t="get"
format="default"/>) or to receive asynchronous DOTS server
<t hangText="DELETE:">DOTS clients use the DELETE method to status messages (<xref target="obs" format="default"/>).</dd>
withdraw a request for mitigation from a DOTS server (<xref <dt>DELETE:</dt>
target="del"></xref>).</t> <dd>DOTS clients use the DELETE method to
</list></t> withdraw a request for mitigation from a DOTS server (<xref target="
del"
format="default"/>).</dd>
</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"
target="RFC7252"></xref>).</t> sectionFormat="of" section="2.2"/>).</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" sectionForma
target="RFC8085"></xref>.</t> t="of"
section="3.1.3"/>.</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 a
Section 3.1.3 of <xref target="RFC8085"></xref>). Mitigation requests nd
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" sectionFormat="of" section="3.1.3"/>). Mitigation
<t>JSON encoding of YANG modeled data <xref target="RFC7951"></xref> requests
<bcp14>MUST NOT</bcp14> be delayed because of checks on probing rate
(<xref target="RFC7252" sectionFormat="of" section="4.7"/>).</t>
<t>JSON encoding of YANG-modeled data <xref target="RFC7951" format="def
ault"/>
is used to illustrate the various methods defined in the following is used to illustrate the various methods defined in the following
subsections. 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>
<t>The DOTS client <bcp14>MUST</bcp14> authenticate itself to the DOTS s
<t>The DOTS client MUST authenticate itself to the DOTS server (<xref erver (<xref target="mutauth" format="default"/>). The DOTS server <bcp14>MAY</b
target="mutauth"></xref>). The DOTS server MAY use the algorithm cp14> use the algorithm
presented in Section 7 of <xref target="RFC7589"></xref> to derive the presented in <xref target="RFC7589" sectionFormat="of" section="7"/> to
derive the
DOTS client identity or username from the client certificate. The DOTS DOTS client identity or username from the client certificate. The DOTS
client identity allows the DOTS server to accept mitigation requests client identity allows the DOTS server to accept mitigation requests
with scopes that the DOTS client is authorized to manage.</t> with scopes that the DOTS client is authorized to manage.</t>
<section anchor="post" numbered="true" toc="default">
<section anchor="post" title="Request Mitigation"> <name>Request Mitigation</name>
<section title="Building Mitigation Requests"> <section numbered="true" toc="default">
<name>Building Mitigation Requests</name>
<t>When a DOTS client requires mitigation for some reason, the <t>When a DOTS client requires mitigation for some reason, the
DOTS client uses the CoAP PUT method to send a mitigation request DOTS client uses the CoAP PUT method to send a mitigation request
to its DOTS server(s) (Figures <xref format="counter" to its DOTS server(s) (Figures <xref format="counter" target="Figure
target="Figure1"></xref> and <xref format="counter" 1"/> and <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 communicating the DOTS client's request to a mitigator (which may
be co-located with the DOTS server) and relaying the feedback of be co-located with the DOTS server) and relaying the feedback of
the thus-selected mitigator to the requesting DOTS client.</t> the 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 type=""><![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
<t>The order of the Uri-Path options is important as it defines the CoAP resource. In particular, 'mid' <bcp14>MUST</bcp14> follow '
the CoAP resource. In particular, 'mid' MUST follow 'cuid'.</t> cuid'.</t>
<t>The additional Uri-Path parameters to those defined in <xref targ
<t>The additional Uri-Path parameters to those defined in <xref et="uri-path" format="default"/> are as follows:</t>
target="uri-path"></xref> are as follows:</t> <dl newline="false" spacing="normal" indent="7">
<dt>cuid:</dt>
<t><list hangIndent="6" style="hanging"> <dd>
<t hangText="cuid:">Stands for Client Unique Identifier. A <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 the reasons discussed in <xref target="motiv" format="default"/>
,
implementations <bcp14>SHOULD</bcp14> set 'cuid' using the follo
wing
procedure: first, the DOTS client inputs one of the following procedure: first, the DOTS client inputs one of the following
into the SHA-256 <xref target="RFC6234"></xref> cryptographic into the SHA-256 <xref target="RFC6234" format="default"/> crypt ographic
hash: the DER-encoded ASN.1 representation of the Subject hash: the DER-encoded ASN.1 representation of the Subject
Public Key Info (SPKI) of its X.509 certificate <xref Public Key Info (SPKI) of its X.509 certificate <xref target="RF
target="RFC5280"></xref>, its raw public key <xref C5280"
target="RFC7250"></xref>, the "Pre-Shared Key (PSK) identity" format="default"/>, its raw public key <xref target="RFC7250"
format="default"/>, the "Pre-Shared Key (PSK) identity"
it uses in the TLS 1.2 ClientKeyExchange message, or the it uses in the TLS 1.2 ClientKeyExchange message, or the
"identity" it uses in the "pre_shared_key" TLS 1.3 extension. "identity" it uses in the "pre_shared_key" TLS 1.3 extension.
Then, the output of the cryptographic hash algorithm is Then, the output of the cryptographic hash algorithm is
truncated to 16 bytes; truncation is done by stripping off the truncated to 16 bytes; truncation is done by stripping off the
final 16 bytes. The truncated output is base64url encoded final 16 bytes. The truncated output is base64url encoded
(Section 5 of <xref target="RFC4648"></xref>) with the two (<xref target="RFC4648" sectionFormat="of" section="5"/>) with t he two
trailing "=" removed from the encoding, and the resulting trailing "=" removed from the encoding, and the resulting
value used as the 'cuid'. <vspace blankLines="1" />The 'cuid' value used as the 'cuid'. </t>
<t>The 'cuid'
is intended to be stable when communicating with a given DOTS is intended to be stable when communicating with a given DOTS
server, i.e., the 'cuid' used by a DOTS client SHOULD NOT server, i.e., the 'cuid' used by a DOTS client <bcp14>SHOULD NOT
change over time. Distinct 'cuid' values MAY be used by a </bcp14>
single DOTS client per DOTS server. <vspace change over time. Distinct 'cuid' values <bcp14>MAY</bcp14> be u
blankLines="1" />If a DOTS client has to change its 'cuid' for sed by a
some reason, it MUST NOT do so when mitigations are still single DOTS client per DOTS server. </t>
active for the old 'cuid'. The 'cuid' SHOULD be 22 characters <t>If a DOTS client has to change its 'cuid' for
some reason, it <bcp14>MUST NOT</bcp14> do so when mitigations a
re still
active for the old 'cuid'. The 'cuid' <bcp14>SHOULD</bcp14> be 2
2 characters
to avoid DOTS signal message fragmentation over UDP. 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, entries at the DOTS server by means of the DOTS data channel,
it MUST delete all the entries bound to the old 'cuid' and it <bcp14>MUST</bcp14> delete all the entries bound to the old '
reinstall them using the new 'cuid'.<vspace cuid' and
blankLines="1" />DOTS servers MUST return 4.09 (Conflict) reinstall them using the new 'cuid'.</t>
<t>DOTS servers <bcp14>MUST</bcp14> return 4.09 (Conflict)
error code to a DOTS peer to notify that the 'cuid' is already error code to a DOTS peer to notify that the 'cuid' is already
in use by another DOTS client. Upon receipt of that error in use by another DOTS client. Upon receipt of that error
code, a new 'cuid' MUST be generated by the DOTS peer (e.g., code, a new 'cuid' <bcp14>MUST</bcp14> be generated by the DOTS
using <xref target="RFC4122"></xref>). <vspace peer (e.g.,
blankLines="1" />Client-domain DOTS gateways MUST handle using <xref target="RFC4122" format="default"/>). </t>
'cuid' collision directly and it is RECOMMENDED that 'cuid' <t>Client-domain DOTS gateways <bcp14>MUST</bcp14> handle
'cuid' collision directly, and it is <bcp14>RECOMMENDED</bcp14>
that 'cuid'
collision is handled directly by server-domain DOTS collision is handled directly by server-domain DOTS
gateways.<vspace blankLines="1" />DOTS gateways MAY rewrite gateways.</t>
<t>DOTS gateways <bcp14>MAY</bcp14> rewrite
the 'cuid' used by peer DOTS clients. Triggers for such the 'cuid' used by peer DOTS clients. Triggers for such
rewriting are out of scope. <vspace blankLines="1" />This is a rewriting are out of scope. </t>
mandatory Uri-Path parameter.</t> <t>This is a mandatory Uri-Path parameter.</t>
</dd>
<t hangText="mid:">Identifier for the mitigation request <dt>mid:</dt>
represented with an integer. This identifier MUST be unique <dd>
<t>Identifier for the mitigation request
represented with an integer. This identifier <bcp14>MUST</bcp14>
be unique
for each mitigation request bound to the DOTS client, i.e., for each mitigation request bound to the DOTS client, i.e.,
the 'mid' parameter value in the mitigation request needs to the 'mid' parameter value in the mitigation request needs to
be unique (per 'cuid' and DOTS server) relative to the 'mid' be unique (per 'cuid' and DOTS server) relative to the 'mid'
parameter values of active mitigation requests conveyed from parameter values of active mitigation requests conveyed from
the DOTS client to the DOTS server.<vspace blankLines="1" />In the DOTS client to the DOTS server.</t>
<t>In
order to handle out-of-order delivery of mitigation requests, order to handle out-of-order delivery of mitigation requests,
'mid' values MUST increase monotonically. <vspace 'mid' values <bcp14>MUST</bcp14> increase monotonically. </t>
blankLines="1" />If the 'mid' value has reached 3/4 of (2^(32) <t>If the 'mid' value has reached 3/4 of (2<sup>(32)</sup>
- 1) (i.e., 3221225471) and no attack is detected, the DOTS - 1) (i.e., 3221225471) and no attack is detected, the DOTS
client MUST reset 'mid' to 0 to handle 'mid' rollover. If the client <bcp14>MUST</bcp14> reset 'mid' to 0 to handle 'mid' roll over. If the
DOTS client maintains mitigation requests with preconfigured DOTS client maintains mitigation requests with preconfigured
scopes, it MUST recreate them with the 'mid' restarting at scopes, it <bcp14>MUST</bcp14> recreate them with the 'mid' rest
0.<vspace blankLines="1" />This identifier MUST be generated arting at
by the DOTS client.<vspace blankLines="1" />This is a 0.</t>
<t>This identifier <bcp14>MUST</bcp14> be generated
by the DOTS client.</t>
<t>This is a
mandatory Uri-Path parameter.</t> mandatory Uri-Path parameter.</t>
</list></t> </dd>
</dl>
<t>'cuid' and 'mid' MUST NOT appear in the PUT request message <t>'cuid' and 'mid' <bcp14>MUST NOT</bcp14> appear in the PUT reques
body (<xref target="Figure1c"></xref>). The schema in <xref t message
target="Figure1c"></xref> uses the types defined in <xref body (<xref target="Figure1c" format="default"/>). The schema in <xr
target="mapping"></xref>. Note that this figure (and other similar ef
figures depicting a schema) are non-normative sketches of the target="Figure1c" format="default"/> uses the types defined in <xref
target="mapping" format="default"/>. Note that this figure (and other
similar
figures depicting a schema) are nonnormative 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 Sche </name>
ma)"> <sourcecode type=""><![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 801 skipping to change at line 710
], ],
"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="
<t>The parameters in the CBOR body (<xref default"/>) of the PUT request are described
target="Figure1c"></xref>) of the PUT request are described
below:</t> 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 resources under attack. Prefixes are represented using
Classless Inter-Domain Routing (CIDR) notation <xref Classless Inter-Domain Routing (CIDR) notation <xref target="RFC
target="RFC4632"></xref>. <vspace blankLines="1" />The prefix 4632"
format="default"/>. </t>
<t>The prefix
length must be less than or equal to 32 for IPv4 and 128 for length must be less than or equal to 32 for IPv4 and 128 for
IPv6.<vspace blankLines="1" />The prefix list MUST NOT include IPv6.</t>
<t>The prefix list <bcp14>MUST NOT</bcp14> include
broadcast, loopback, or multicast addresses. These addresses broadcast, loopback, or multicast addresses. These addresses
are considered to be invalid values. In addition, the DOTS are considered to be invalid values. In addition, the DOTS
server MUST validate that target prefixes are within the scope server <bcp14>MUST</bcp14> validate that target prefixes are wit hin the scope
of the DOTS client domain. Other validation checks may be of the DOTS client domain. Other validation checks may be
supported by DOTS servers.<vspace blankLines="1" />This is an supported by DOTS servers.</t>
optional attribute.</t> <t>This is an optional attribute.</t>
</dd>
<t hangText="target-port-range:">A list of port numbers bound <dt>target-port-range:</dt>
to resources under attack. <vspace blankLines="1" />A port <dd>
range is defined by two bounds, a lower port number <t>A list of port numbers bound to resources under attack. </t>
<t>A port
range is defined by two bounds: a lower port number
('lower-port') and an upper port number ('upper-port'). When ('lower-port') and an upper port number ('upper-port'). When
only 'lower-port' is present, it represents a single port only 'lower-port' is present, it represents a single port
number.<vspace blankLines="1" />For TCP, UDP, Stream Control number.</t>
Transmission Protocol (SCTP) <xref target="RFC4960"></xref>, <t>For TCP, UDP, Stream Control
or Datagram Congestion Control Protocol (DCCP) <xref Transmission Protocol (SCTP) <xref target="RFC4960" format="defa
target="RFC4340"></xref>, a range of ports can be, for ult"/>,
example, 0-1023, 1024-65535, or 1024-49151. <vspace or Datagram Congestion Control Protocol (DCCP) <xref target="RFC
blankLines="1" />This is an optional attribute.</t> 4340"
format="default"/>, a range of ports can be, for
<t hangText="target-protocol:">A list of protocols involved in example, 0-1023, 1024-65535, or 1024-49151. </t>
<t>This is an optional attribute.</t>
</dd>
<dt>target-protocol:</dt>
<dd>
<t>A list of protocols involved in
an attack. Values are integers in the range of 0 to 255. See an attack. Values are integers in the range of 0 to 255. See
<xref target="IANA-Proto"></xref> for common values. <vspace <xref target="IANA-Proto" format="default"/> for common values.
blankLines="1" />If 'target-protocol' is not specified, then </t>
the request applies to any protocol. <vspace <t>If 'target-protocol' is not specified, then
blankLines="1" />This is an optional attribute.</t> the request applies to any protocol. </t>
<t>This is an optional attribute.</t>
<t hangText="target-fqdn:">A list of Fully Qualified Domain </dd>
Names (FQDNs) identifying resources under attack <xref <dt>target-fqdn:</dt>
target="RFC8499"></xref>.<vspace blankLines="1" />How a name <dd>
<t>A list of Fully Qualified Domain
Names (FQDNs) identifying resources under attack <xref target="R
FC8499" format="default"/>.</t>
<t>How a name
is passed to an underlying name resolution library is 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 name is resolved into one or multiple IP addresses, DOTS
servers MUST apply the same validation checks as those for servers <bcp14>MUST</bcp14> apply the same validation checks as those for
'target-prefix'. These validation checks are reiterated by 'target-prefix'. These validation checks are reiterated by
DOTS servers each time a name is passed to an underlying name DOTS servers each time a name is passed to an underlying name
resolution library (e.g., upon expiry of DNS TTL).<vspace resolution library (e.g., upon expiry of DNS TTL).</t>
blankLines="1" />The use of FQDNs may be suboptimal <t>The use of FQDNs may be suboptimal
because:<list style="symbols"> because:</t>
<t>It induces both an extra load and increased delays on <ul spacing="normal">
<li>It induces both an extra load and increased delays on
the DOTS server to handle and manage DNS resolution the DOTS server to handle and manage DNS resolution
requests.</t> requests.</li>
<li>It does not guarantee that the DOTS server will resolve
<t>It does not guarantee that the DOTS server will resolve
a name to the same IP addresses that the DOTS client a name to the same IP addresses that the DOTS client
does.</t> does.</li>
</list><vspace blankLines="1" />This is an optional </ul>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="target-uri:">A list of URIs <xref <dt>target-uri:</dt>
target="RFC3986"></xref> identifying resources under attack. <dd>
<vspace blankLines="1" />The same validation checks used for <t>A list of URIs <xref target="RFC3986" format="default"/> iden
'target-fqdn' MUST be followed by DOTS servers to validate a tifying
target URI. <vspace blankLines="1" />This is an optional resources under attack.</t>
<t>The same validation checks used for
'target-fqdn' <bcp14>MUST</bcp14> be followed by DOTS servers to
validate a
target URI. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="alias-name:">A list of aliases of resources for <dt>alias-name:</dt>
<dd>
<t>A list of aliases of resources for
which the mitigation is requested. Aliases can be created which the mitigation is requested. Aliases can be created
using the DOTS data channel (Section 6.1 of <xref using the DOTS data channel (<xref target="RFC8783"
target="RFC8783"></xref>), direct configuration, or other sectionFormat="of" section="6.1"/>), direct configuration, or oth
means. <vspace blankLines="1" />An alias is used in subsequent er
means. </t>
<t>An alias is used in subsequent
signal channel exchanges to refer more efficiently to the signal channel exchanges to refer more efficiently to the
resources under attack.<vspace blankLines="1" />This is an resources under attack.</t>
<t>This is an
optional attribute.</t> 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
refreshing is not typically a burden on the DOTS client, while seconds. The <bcp14>RECOMMENDED</bcp14> lifetime of a mitigation
request is
3600 seconds; this value was chosen to be long enough so that
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> i
parameter in their mitigation requests. <vspace nclude this
blankLines="1" />A lifetime of '0' in a mitigation request is parameter in their mitigation requests. </t>
an invalid value. <vspace blankLines="1" />A lifetime of <t>A lifetime of '0' in a mitigation request is
an invalid value. </t>
<t>A lifetime of
negative one (-1) indicates indefinite lifetime for the negative one (-1) indicates indefinite lifetime for the
mitigation request. The DOTS server MAY refuse an indefinite mitigation request. The DOTS server <bcp14>MAY</bcp14> refuse an indefinite
lifetime, for policy reasons; the granted lifetime value is lifetime, for policy reasons; the granted lifetime value is
returned in the response. DOTS clients MUST be prepared to not returned in the response. DOTS clients <bcp14>MUST</bcp14> be pr
be granted mitigations with indefinite lifetimes.<vspace epared to not
blankLines="1" />The DOTS server MUST always indicate the be granted mitigations with indefinite lifetimes.</t>
<t>The DOTS server <bcp14>MUST</bcp14> always indicate the
actual lifetime in the response and the remaining lifetime in actual lifetime in the response and the remaining lifetime in
status messages sent to the DOTS client. <vspace status messages sent to the DOTS client. </t>
blankLines="1" />Upon the expiry of the negotiated lifetime <t>Upon the expiry of the negotiated lifetime
(i.e., the remaining lifetime reaches '0'), and if the request (i.e., the remaining lifetime reaches '0'), and if the request
is not refreshed by the DOTS client, the mitigation request is is not refreshed by the DOTS client, the mitigation request is
removed by the DOTS server. The request can be refreshed by removed by the DOTS server. The request can be refreshed by
sending the same request again. <vspace blankLines="1" />This sending the same request again. </t>
<t>This
is a mandatory attribute.</t> is a mandatory attribute.</t>
</dd>
<t hangText="trigger-mitigation:">If the parameter value is <dt>trigger-mitigation:</dt>
<dd>
<t>If the parameter value is
set to 'false', DDoS mitigation will not be triggered for the set 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' equivalent to receiving a request with 'trigger-mitigation'
set to 'true'. <vspace blankLines="1" />This is an optional set to 'true'. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</list></t> </dd>
</dl>
<t>Because of the complexity of handling partial failure cases, <t>Because of the complexity of handling partial failure cases,
this specification does not allow the inclusion of multiple this specification does not allow the inclusion of multiple
mitigation requests in the same PUT request. Concretely, a DOTS mitigation requests in the same PUT request. Concretely, a DOTS
client MUST NOT include multiple entries in the 'scope' array of client <bcp14>MUST NOT</bcp14> include multiple entries in the 'scop e' array of
the same PUT request.</t> the same PUT 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 scope alias, in which the addresses associated with the domain
name or URI (as resolved by the DOTS server) represent the scope name or URI (as resolved by the DOTS server) represent the scope
of the mitigation. Particularly, the IP addresses to which the of the mitigation. Particularly, the IP addresses to which the
host subcomponent of authority component of a URI resolves host subcomponent of authority component of a URI resolves
represent the 'target-prefix', the URI scheme represents the represent the 'target-prefix', the URI scheme represents the
'target-protocol', the port subcomponent of authority component of 'target-protocol', and the port subcomponent of authority component of
a URI represents the 'target-port-range'. If the optional port a URI represents the 'target-port-range'. If the optional port
information is not present in the authority component, the default information is not present in the authority component, the default
port defined for the URI scheme represents the 'target-port'.</t> port defined for the 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' MUST 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' <bcp14> MUST</bcp14>
be present.</t> be present.</t>
<t>Attributes and Uri-Path parameters with empty values <bcp14>MUST
<t>Attributes and Uri-Path parameters with empty values MUST NOT NOT</bcp14>
be present in a request as an empty value will render the entire be present in a request, as an empty value will render the entire
request invalid.</t> request invalid.</t>
<t><xref target="Figure2" format="default"/> shows a PUT request exa
<t><xref target="Figure2"></xref> shows a PUT request example to mple to
signal that servers 2001:db8:6401::1 and 2001:db8:6401::2 are signal that servers 2001:db8:6401::1 and 2001:db8:6401::2 are
receiving attack traffic on TCP port numbers 80, 8080, and 443. receiving attack traffic on TCP port numbers 80, 8080, and 443.
The presence of 'cdid' indicates that a server-domain DOTS gateway The presence of 'cdid' indicates that a server-domain DOTS gateway
has modified the initial PUT request sent by the DOTS client. Note has modified the initial PUT request sent by the DOTS client. Note
that 'cdid' MUST NOT appear in the PUT request message body.</t> that 'cdid' <bcp14>MUST NOT</bcp14> appear in the PUT request messag
e 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 type=""><![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 988 skipping to change at line 917
} }
], ],
"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 type="cbor"><![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) A4 # map(4)
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)
skipping to change at line 1024 skipping to change at line 952
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)
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Server-domain DOTS Gateways"> <name>Server-Domain DOTS Gateways</name>
<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 identity information about the origin source client domain
('cdid') SHOULD be propagated to the DOTS server. That information ('cdid') <bcp14>SHOULD</bcp14> be propagated to the DOTS server. Tha
is meant to assist the DOTS server in enforcing some policies such t information
is meant to assist the DOTS server in enforcing some policies, such
as grouping DOTS clients that belong to the same DOTS domain, as grouping DOTS clients that belong to the same DOTS domain,
limiting the number of DOTS requests, and identifying the limiting the number of DOTS requests, and identifying the
mitigation scope. These policies can be enforced per client, per mitigation scope. These policies can be enforced per client, per
client domain, or both. Also, the identity information may be used client domain, or both. Also, the identity information may be used
for auditing and debugging purposes.</t> for auditing and debugging purposes.</t>
<t><xref target="Figure1a" format="default"/> shows an example of a
<t><xref target="Figure1a"></xref> shows an example of a request request
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 Gate </name>
way"> <sourcecode type=""><![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 follow
<t>A server-domain DOTS gateway SHOULD add the following Uri-Path ing Uri-Path
parameter:</t> parameter:</t>
<dl newline="false" spacing="normal" indent="7">
<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 'cdid' is conveyed by a server-domain DOTS gateway to
propagate the source domain identity from the gateway's propagate the source domain identity from the gateway's
client-facing side to the gateway's server-facing side, and client-facing side to the gateway's server-facing side and
from the gateway's server-facing side to the DOTS server. from the gateway's server-facing side to the DOTS server.
'cdid' may be used by the final DOTS server for policy 'cdid' may be used by the final DOTS server for policy-enforceme
enforcement purposes (e.g., enforce a quota on filtering nt
rules). These policies are deployment specific.<vspace purposes (e.g., enforce a quota on filtering
blankLines="1" />Server-domain DOTS gateways SHOULD support a rules). These policies are deployment specific.</t>
configuration option to instruct whether 'cdid' parameter is <t>Server-domain DOTS gateways <bcp14>SHOULD</bcp14> support a
to be inserted. <vspace blankLines="1" />In order to configuration option to instruct whether the 'cdid' parameter is
accommodate deployments that require enforcing per- client to be inserted. </t>
<t>In order to
accommodate deployments that require enforcing per-client
policies, per-client domain policies, or a combination policies, per-client domain policies, or a combination
thereof, server-domain DOTS gateways instructed to insert the thereof, server-domain DOTS gateways instructed to insert the
'cdid' parameter MUST supply the SPKI hash of the DOTS client 'cdid' parameter <bcp14>MUST</bcp14> supply the SPKI hash of the DOTS client
X.509 certificate, the DOTS client raw public key, or the hash X.509 certificate, the DOTS client raw public key, or the hash
of the "PSK identity" in the 'cdid', following the same rules of the "PSK identity" in the 'cdid', following the same rules
for generating the hash conveyed in 'cuid', which is then used for generating the hash conveyed in 'cuid', which is then used
by the ultimate DOTS server to determine the corresponding by the ultimate DOTS server to determine the corresponding
client's domain. The 'cdid' generated by a server-domain client's domain. The 'cdid' generated by a server-domain
gateway is likely to be the same as the 'cuid' except the case gateway is likely to be the same as the 'cuid' except the case
in which the DOTS message was relayed by a client-domain DOTS in which the DOTS message was relayed by a client-domain DOTS
gateway or the 'cuid' was generated by a rogue DOTS gateway or the 'cuid' was generated by a rogue DOTS
client.<vspace blankLines="1" />If a DOTS client is client.</t>
<t>If a DOTS client is
provisioned, for example, with distinct certificates to use to provisioned, for example, with distinct certificates to use to
peer with distinct server-domain DOTS gateways that peer to peer with distinct server-domain DOTS gateways that peer to
the same DOTS server, distinct 'cdid' values may be supplied the same DOTS server, distinct 'cdid' values may be supplied
by the server-domain DOTS gateways to the server. The ultimate by the server-domain DOTS gateways to the server. The ultimate
DOTS server MUST treat those 'cdid' values as equivalent. DOTS server <bcp14>MUST</bcp14> treat those 'cdid' values as equ
<vspace blankLines="1" />The 'cdid' attribute MUST NOT be ivalent.
generated and included by DOTS clients. <vspace </t>
blankLines="1" />DOTS servers MUST ignore 'cdid' attributes <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 that are directly supplied by source DOTS clients or
client-domain DOTS gateways. This implies that first client-domain DOTS gateways. This implies that first
server-domain DOTS gateways MUST strip 'cdid' attributes server-domain DOTS gateways <bcp14>MUST</bcp14> strip 'cdid' att
supplied by DOTS clients. DOTS servers SHOULD support a ributes
supplied by DOTS clients. DOTS servers <bcp14>SHOULD</bcp14> sup
port a
configuration parameter to identify DOTS gateways that are configuration parameter to identify DOTS gateways that are
trusted to supply 'cdid' attributes.<vspace trusted to supply 'cdid' attributes.</t>
blankLines="1" />Only single-valued 'cdid' are defined in this <t>Only single-valued 'cdid' are defined in this
document. That is, only the first on-path server-domain DOTS document. That is, only the first on-path server-domain DOTS
gateway can insert a 'cdid' value. This specification does not gateway can insert a 'cdid' value. This specification does not
allow multiple server-domain DOTS gateways, whenever involved allow multiple server-domain DOTS gateways, whenever involved
in the path, to insert a 'cdid' value for each server-domain in the path, to insert a 'cdid' value for each server-domain
gateway. <vspace blankLines="1" />This is an optional gateway. </t>
Uri-Path. When present, 'cdid' MUST be positioned before <t>This is an optional
Uri-Path. When present, 'cdid' <bcp14>MUST</bcp14> be positioned
before
'cuid'.</t> '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 Optio
target="RFC8768"></xref>.</t> n <xref
target="RFC8768" format="default"/>.</t>
</section> </section>
<section anchor="pro-mit-req" numbered="true" toc="default">
<section title="Processing Mitigation Requests"> <name>Processing Mitigation Requests</name>
<t>The DOTS server couples the DOTS signal and data channel <t>The DOTS server couples the DOTS signal and data channel
sessions using the DOTS client identity and optionally the 'cdid' sessions using the DOTS client identity and optionally the 'cdid'
parameter value, so the DOTS server can validate whether the parameter value, so the DOTS server can validate whether the
aliases conveyed in the mitigation request were indeed created by aliases conveyed in the mitigation request were indeed created by
the same DOTS client using the DOTS data channel session. If the the same DOTS client using the DOTS data channel session. If the
aliases were not created by the DOTS client, the DOTS server MUST aliases were not created by the DOTS client, the DOTS server <bcp14> MUST</bcp14>
return 4.00 (Bad Request) in the response.</t> return 4.00 (Bad 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 the DOTS client identity and optionally the 'cdid' parameter
value, and the DOTS server uses 'mid' and 'cuid' Uri-Path value, and the DOTS server uses 'mid' and 'cuid' Uri-Path
parameter values to detect duplicate mitigation requests. If the parameter values to detect duplicate mitigation requests. If the
mitigation request contains the 'alias-name' and other parameters mitigation request contains the 'alias-name' and other parameters
identifying the target resources (such as 'target-prefix', identifying the target resources (such as 'target-prefix',
'target-port-range', 'target-fqdn', or 'target-uri'), the DOTS 'target-port-range', 'target-fqdn', or 'target-uri'), the DOTS
server appends the parameter values associated with the server appends the parameter values associated with the
'alias-name' with the corresponding parameter values in 'alias-name' with the corresponding parameter values in
'target-prefix', 'target-port-range', 'target-fqdn', or 'target-prefix', 'target-port-range', 'target-fqdn', or
skipping to change at line 1137 skipping to change at line 1065
the DOTS client identity and optionally the 'cdid' parameter the DOTS client identity and optionally the 'cdid' parameter
value, and the DOTS server uses 'mid' and 'cuid' Uri-Path value, and the DOTS server uses 'mid' and 'cuid' Uri-Path
parameter values to detect duplicate mitigation requests. If the parameter values to detect duplicate mitigation requests. If the
mitigation request contains the 'alias-name' and other parameters mitigation request contains the 'alias-name' and other parameters
identifying the target resources (such as 'target-prefix', identifying the target resources (such as 'target-prefix',
'target-port-range', 'target-fqdn', or 'target-uri'), the DOTS 'target-port-range', 'target-fqdn', or 'target-uri'), the DOTS
server appends the parameter values associated with the server appends the parameter values associated with the
'alias-name' with the corresponding parameter values in 'alias-name' with the corresponding parameter values in
'target-prefix', 'target-port-range', 'target-fqdn', or '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. 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 CoAP 5.xx codes are returned if the DOTS server is in an error
state or is currently unavailable to provide mitigation in state or is currently unavailable to provide mitigation in
response to the mitigation request from the DOTS client.</t> response to the mitigation request from the DOTS client.</t>
<t><xref target="put_response" format="default"/> shows an example r
<t><xref target="put_response"></xref> shows an example response esponse
to a PUT request that is successfully processed by a DOTS server to a PUT request that is successfully processed by a DOTS server
(i.e., CoAP 2.xx Response Codes). This version of the (i.e., CoAP 2.xx Response Codes). This version of the
specification forbids 'cuid' and 'cdid' (if used) to be returned specification forbids 'cuid' and 'cdid' (if used) to be returned
in a response message body.</t> in a response message 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 type=""><![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 <t>If the request is missing a mandatory attribute, does not
include 'cuid' or 'mid' Uri-Path options, includes multiple include 'cuid' or 'mid' Uri-Path options, includes multiple
'scope' parameters, or contains invalid or unknown parameters, the 'scope' parameters, or contains invalid or unknown parameters, the
DOTS server MUST reply with 4.00 (Bad Request). DOTS agents can DOTS server <bcp14>MUST</bcp14> reply with 4.00 (Bad Request). DOTS agents can
safely ignore comprehension-optional parameters they don't safely ignore comprehension-optional parameters they don't
understand (<xref target="format"></xref>).</t> understand (<xref target="format" format="default"/>).</t>
<t>A DOTS server that receives a mitigation request with a <t>A DOTS server that receives a mitigation request with a
'lifetime' set to '0' MUST reply with a 4.00 (Bad Request).</t> 'lifetime' set to '0' <bcp14>MUST</bcp14> reply with a 4.00 (Bad Req
uest).</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 conveyed in the PUT request in its configuration data, it <bcp14>MAY </bcp14>
accept the mitigation request by sending back a 2.01 (Created) accept the mitigation request by sending back a 2.01 (Created)
response to the DOTS client; the DOTS server will consequently try response to the DOTS client; the DOTS server will consequently try
to mitigate the attack. A DOTS server MAY reject mitigation to mitigate the attack. A DOTS server <bcp14>MAY</bcp14> reject miti gation
requests when it is near capacity or needs to rate-limit a requests when it is near capacity or needs to rate-limit a
particular client, for example.</t> particular client, for example.</t>
<t>The relative order of two mitigation requests with the same <t>The relative order of two mitigation requests with 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 comparing their respective 'mid' values. If two mitigation
requests with the same 'trigger-mitigation' type have overlapping requests with the same 'trigger-mitigation' type have overlapping
mitigation scopes, the mitigation request with the highest numeric mitigation scopes, the mitigation request with the highest numeric
'mid' value will override the other mitigation request. Two 'mid' value will override the other mitigation request. Two
mitigation requests from a DOTS client have overlapping scopes if mitigation requests from a DOTS client have overlapping scopes if
there is a common IP address, IP prefix, FQDN, URI, or alias. To there is a common IP address, IP prefix, FQDN, URI, or alias. To
avoid maintaining a long list of overlapping mitigation requests avoid maintaining a long list of overlapping mitigation requests
(i.e., requests with the same 'trigger-mitigation' type and (i.e., requests with the same 'trigger-mitigation' type and
skipping to change at line 1194 skipping to change at line 1118
comparing their respective 'mid' values. If two mitigation comparing their respective 'mid' values. If two mitigation
requests with the same 'trigger-mitigation' type have overlapping requests with the same 'trigger-mitigation' type have overlapping
mitigation scopes, the mitigation request with the highest numeric mitigation scopes, the mitigation request with the highest numeric
'mid' value will override the other mitigation request. Two 'mid' value will override the other mitigation request. Two
mitigation requests from a DOTS client have overlapping scopes if mitigation requests from a DOTS client have overlapping scopes if
there is a common IP address, IP prefix, FQDN, URI, or alias. To there is a common IP address, IP prefix, FQDN, URI, or alias. To
avoid maintaining a long list of overlapping mitigation requests avoid maintaining a long list of overlapping mitigation requests
(i.e., requests with the same 'trigger-mitigation' type and (i.e., requests with the same 'trigger-mitigation' type and
overlapping scopes) from a DOTS client and to avoid error-prone overlapping scopes) from a DOTS client and to avoid error-prone
provisioning of mitigation requests from a DOTS client, the provisioning of mitigation requests from a DOTS client, the
overlapped lower numeric 'mid' MUST be automatically deleted and overlapped lower numeric 'mid' <bcp14>MUST</bcp14> be automatically deleted and
no longer available at the DOTS server. For example, if the DOTS no longer available at the DOTS server. For example, if the DOTS
server receives a mitigation request that overlaps with an server receives a mitigation request that overlaps with an
existing mitigation with a higher numeric 'mid', the DOTS server existing mitigation with a higher numeric 'mid', the DOTS server
rejects the request by returning 4.09 (Conflict) to the DOTS rejects the request by returning 4.09 (Conflict) to the DOTS
client. The response MUST include enough information for a DOTS client. The response <bcp14>MUST</bcp14> include enough information
client to recognize the source of the conflict as described below for a DOTS
in the 'conflict-information' subtree (<xref client to recognize the source of the conflict, as described below
target="tree"></xref>) with only the relevant nodes listed:</t> in the 'conflict-information' subtree (<xref target="tree" format="d
efault"/>),
<t hangText="status:"><list style="hanging"> with only the relevant nodes listed:</t>
<t hangText="conflict-information:">Indicates that a <dl newline="false" spacing="normal">
<dt>conflict-information:</dt>
<dd>
<t>Indicates that a
mitigation request is conflicting with another mitigation mitigation request is conflicting with another mitigation
request. This attribute has the following structure: <list request. This attribute has the following structure: </t>
style="hanging"> <dl newline="false" spacing="normal">
<t hangText="conflict-cause:">Indicates the cause of the <dt>conflict-cause:</dt>
conflict. The following value MUST be returned:<list <dd>
style="format %d:"> <t>Indicates the cause of the
<t>Overlapping targets. 'conflict-scope' provides more conflict. The following value <bcp14>MUST</bcp14> be returne
details about the conflicting target clauses.</t> d:</t>
</list></t> <dl newline="false" spacing="normal">
<dt>1:</dt>
<t hangText="conflict-scope:">Characterizes the exact <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 conflict scope. It may include a list of IP addresses, a
list of prefixes, a list of target protocols, a list of list of prefixes, a list of target protocols, a list of
FQDNs, a list of URIs, a list of aliases, or a 'mid'. A FQDNs, a list of URIs, a list of aliases, or a 'mid'. A
list of port numbers may also be included if there is a list of port numbers may also be included if there is a
common IP address, IP prefix, FQDN, URI, or alias.</t> common IP address, IP prefix, FQDN, URI, or alias.</dd>
</list></t> </dl>
</list></t> </dd>
</dl>
<t>If the DOTS server receives a mitigation request that overlaps <t>If the DOTS server receives a mitigation request that overlaps
with an active mitigation request, but both have distinct with an active mitigation request, but both have distinct
'trigger- mitigation' types, the DOTS server SHOULD deactivate 'trigger- mitigation' types, the DOTS server <bcp14>SHOULD</bcp14> d eactivate
(absent explicit policy/configuration otherwise) the mitigation (absent explicit policy/configuration otherwise) the mitigation
request with 'trigger- mitigation' set to 'false'. Particularly, request with 'trigger- mitigation' set to 'false'. Particularly,
if the mitigation request with 'trigger-mitigation' set to 'false' if the mitigation request with 'trigger-mitigation' set to 'false'
is active, the DOTS server withdraws the mitigation request (i.e., is active, the DOTS server withdraws the mitigation request (i.e.,
status code is set to '7' as defined in Table 3) and transitions status code is set to '7' as defined in <xref target="table3" format
="default"/>)
and transitions
the status of the mitigation request to '8'.</t> 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
that overlap with mitigation requests having 'trigger-mitigation' that overlap with mitigation requests having 'trigger-mitigation'
set to 'false' from that DOTS client, as the loss of the session set 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 the active-but-terminating period they take precedence. Note that the active-but-terminating period
is not observed for mitigations withdrawn at the initiative of the is not observed for mitigations withdrawn at the initiative of the
DOTS server.</t> DOTS server.</t>
<t>DOTS clients may adopt various strategies for setting the <t>DOTS clients may adopt various strategies for setting the
scopes of immediate and preconfigured mitigation requests to avoid scopes 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
preconfigured scopes so that the scope of any overlapping preconfigured scopes so that the scope of any overlapping
immediate mitigation request will be a subset of the preconfigured immediate mitigation request will be a subset of the preconfigured
scopes. Also, if an immediate mitigation request overlaps with any scopes. Also, if an immediate mitigation request overlaps with any
of the preconfigured scopes, the DOTS client sets the scope of the 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
preconfigured scopes, so as to get a broad mitigation when the preconfigured scopes, so as to get a broad mitigation when the
DOTS signal channel collapses and to maximize the chance of DOTS signal channel collapses and to maximize the chance of
skipping to change at line 1256 skipping to change at line 1185
scopes of immediate and preconfigured mitigation requests to avoid scopes 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
preconfigured scopes so that the scope of any overlapping preconfigured scopes so that the scope of any overlapping
immediate mitigation request will be a subset of the preconfigured immediate mitigation request will be a subset of the preconfigured
scopes. Also, if an immediate mitigation request overlaps with any scopes. Also, if an immediate mitigation request overlaps with any
of the preconfigured scopes, the DOTS client sets the scope of the 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
preconfigured scopes, so as to get a broad mitigation when the preconfigured scopes, so as to get a broad mitigation when the
DOTS signal channel collapses and to maximize the chance of DOTS signal channel collapses and to maximize the chance of
recovery.</t> recovery.</t>
<t>If the request conflicts with an existing mitigation request <t>If the request conflicts 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 server decides to maintain the new mitigation request, the
DOTS server returns 2.01 (Created) to the requesting DOTS client. DOTS server returns 2.01 (Created) to the requesting DOTS client.
If the DOTS server decides to reject the new mitigation request, If the DOTS server decides to reject the new mitigation request,
the DOTS server returns 4.09 (Conflict) to the requesting DOTS the DOTS server returns 4.09 (Conflict) to the requesting DOTS
client. For both 2.01 (Created) and 4.09 (Conflict) responses, the client. For both 2.01 (Created) and 4.09 (Conflict) responses, the
response MUST include enough information for a DOTS client to response <bcp14>MUST</bcp14> include enough information for a DOTS c lient to
recognize the source of the conflict as described below:</t> recognize the source of the conflict as described below:</t>
<dl newline="false" spacing="normal">
<t hangText="status:"><list style="hanging"> <dt>conflict-information:</dt>
<t hangText="conflict-information:">Indicates that a <dd>
<t>Indicates that a
mitigation request is conflicting with another mitigation mitigation request is conflicting with another mitigation
request(s) from other DOTS client(s). This attribute has the request(s) from other DOTS client(s). This attribute has the
following structure: <list style="hanging"> following 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 newline="false" spacing="normal" indent="6">
<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 newline="false" spacing="normal" indent="6">
<dt>1:</dt>
<t>Conflicts with an existing accept-list. This code <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 is returned when the DDoS mitigation detects source
addresses/prefixes in the accept-listed ACLs are addresses/prefixes in the accept-listed Access Control
attacking the target.</t> Lists (ACLs) are 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 DOTS client. This code is an indication that the
request has been rejected and a new request with a new request has been rejected and a new request with a new
'cuid' is to be re-sent by the DOTS client (see the 'cuid' is to be re-sent by the DOTS client (see the
example shown in <xref target="newcuid"></xref>). Note example shown in <xref target="newcuid" format="default" />). Note
that 'conflict-status', 'conflict-scope', and that 'conflict-status', 'conflict-scope', and
'retry-timer' MUST NOT be returned in the error 'retry-timer' <bcp14>MUST NOT</bcp14> be returned in the
response.</t> error
</list></t> response.</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 target protocols, a list of list of prefixes, a list of target protocols, a list of
FQDNs, a list of URIs, a list of aliases, or references to FQDNs, a list of URIs, a list of aliases, or references to
conflicting ACLs (by an 'acl-name', typically <xref conflicting ACLs (by an 'acl-name', typically <xref target="
target="RFC8783"></xref>). A list of port numbers may also RFC8783" format="default"/>). A list of port numbers may also
be included if there is a common IP address, IP prefix, be included if there is a common IP address, IP prefix,
FQDN, URI, or alias.</t> FQDN, URI, or alias.</dd>
<dt>retry-timer:</dt>
<t hangText="retry-timer:">Indicates, in seconds, the time <dd>
<t>Indicates, in seconds, the time
after which the DOTS client may reissue the same request. after which the DOTS client may reissue the same request.
The DOTS server returns 'retry-timer' only to DOTS The DOTS server returns 'retry-timer' only to DOTS
client(s) for which a mitigation request is deactivated. client(s) for which a mitigation request is deactivated.
Any retransmission of the same mitigation request before Any retransmission of the same mitigation request before
the expiry of this timer is likely to be rejected by the the expiry of this timer is likely to be rejected by the
DOTS server for the same reasons.<vspace DOTS server for the same reasons.</t>
blankLines="1" />The 'retry-timer' SHOULD be equal to the <t>The 'retry-timer' <bcp14>SHOULD</bcp14> be equal to the
lifetime of the active mitigation request resulting in the lifetime of the active mitigation request resulting in the
deactivation of the conflicting mitigation request. deactivation of the conflicting mitigation request.
<vspace blankLines="1" />If the DOTS server decides to </t>
<t>If the DOTS server decides to
maintain a state for the deactivated mitigation request, maintain a state for the deactivated mitigation request,
the DOTS server updates the lifetime of the deactivated the DOTS server updates the lifetime of the deactivated
mitigation request to 'retry-timer + 45 seconds' (that is, mitigation request to 'retry-timer + 45 seconds' (that is,
this mitigation request remains deactivated for the entire this mitigation request remains deactivated for the entire
duration of 'retry-timer + 45 seconds') so that the DOTS duration of 'retry-timer + 45 seconds') so that the DOTS
client can refresh the deactivated mitigation request client can refresh the deactivated mitigation request
after 'retry-timer' seconds, but before the expiry of the after 'retry-timer' seconds, but before the expiry of the
lifetime, and check if the conflict is resolved.</t> lifetime, and check if the 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[ (1) Request with a conflicting 'cuid' <name>Example of Generating a New 'cuid'</name>
<sourcecode type=""><![CDATA[
(1) Request with a conflicting 'cuid'
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=12" Uri-Path: "mid=12"
(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
skipping to change at line 1377 skipping to change at line 1318
} }
(3) Request with a new 'cuid' (3) Request with a new 'cuid'
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"
]]></sourcecode>
]]></artwork> </figure>
</figure>As an active attack evolves, DOTS clients can adjust <t>As an active attack evolves, DOTS clients can adjust
the scope of requested mitigation as necessary, by refining the the scope of requested mitigation as necessary, by refining the
scope of resources requiring mitigation. This can be achieved by scope of resources requiring mitigation. This can be achieved by
sending a PUT request with a new 'mid' value that will override sending a PUT request with a new 'mid' value that will override
the existing one with overlapping mitigation scopes.</t> the existing one with overlapping mitigation 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 continue beyond the initial negotiated lifetime, the DOTS client
has to refresh the current mitigation request by sending a new PUT has to refresh the current mitigation request by sending a new PUT
request. This PUT request MUST use the same 'mid' value, and it request. This PUT request <bcp14>MUST</bcp14> use the same 'mid' val
MUST repeat all the other parameters as sent in the original ue, and it
<bcp14>MUST</bcp14> repeat all the other parameters as sent in the o
riginal
mitigation request apart from a possible change to the 'lifetime' mitigation request apart from a possible change to the 'lifetime'
parameter value. In such a case, the DOTS server MAY update the parameter value. In such a case, the DOTS server <bcp14>MAY</bcp14> update the
mitigation request by setting the remaining lifetime to the newly mitigation request by setting the remaining lifetime to the newly
negotiated lifetime, and a 2.04 (Changed) response is returned to negotiated lifetime, and a 2.04 (Changed) response is returned to
indicate a successful update of the mitigation request. If this is indicate a successful update of the mitigation request. If this is
not the case, the DOTS server MUST reject the request with a 4.00 not the case, the DOTS server <bcp14>MUST</bcp14> reject the request with a 4.00
(Bad Request).</t> (Bad Request).</t>
</section> </section>
</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 the 'cdid' parameter by
server-domain DOTS gateways specified in <xref target="post"></xref> server-domain DOTS gateways specified in <xref target="post" format="d
MUST be followed for GET requests.</t> efault"/>
<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 Table 2 (content) parameter and its permitted values defined in Table 2 of
<xref target="I-D.ietf-core-comi"></xref> can be used to retrieve <xref target="I-D.ietf-core-comi" format="default"/> can be used to re
trieve
non-configuration data (attack mitigation status), configuration non-configuration data (attack mitigation status), configuration
data, or both. The DOTS server MAY support this optional filtering data, or both. The DOTS server <bcp14>MAY</bcp14> support this optiona l filtering
capability. It can safely ignore it if not supported. If the DOTS capability. It can safely ignore it if not supported. If the DOTS
client supports the optional filtering capability, it SHOULD use client supports the optional filtering capability, it <bcp14>SHOULD</b cp14> use
"c=n" query (to get back only the dynamically changing data) or "c=n" query (to get back only the dynamically changing data) or
"c=c" query (to get back the static configuration values) when the "c=c" query (to get back the static configuration values) when the
DDoS attack is active to limit the size of the response.</t> DDoS attack is active to limit the size of the response.</t>
<table anchor="table2" align="center">
<figure> <name>Permitted Values of the 'c' Parameter</name>
<artwork align="center"><![CDATA[+-------+-------------------------- <thead>
---------------------------+ <tr>
| Value | Description | <th>Value</th>
+=======+=====================================================+ <th>Description</th>
| c | Return only configuration descendant data nodes | </tr>
+-------+-----------------------------------------------------+ </thead>
| n | Return only non-configuration descendant data nodes | <tbody>
+-------+-----------------------------------------------------+ <tr>
| a | Return all descendant data nodes | <td>c</td>
+-------+-----------------------------------------------------+ <td>Return only configuration descendant data nodes</td>
</tr>
Table 2: Permitted Values of the 'c' Parameter]]></artwork> <tr>
</figure> <td>n</td>
<td>Return only non-configuration descendant data nodes</td>
<t>The DOTS client can use block-wise transfer <xref </tr>
target="RFC7959"></xref> to get the list of all its mitigations <tr>
maintained by a DOTS server, it can send a Block2 Option in a GET <td>a</td>
<td>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 it was processed by response is formatted in the same order as it was processed by
the DOTS server in the original mitigation request.</t> the 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 type=""><![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 type=""><![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 type=""><![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 1553 skipping to change at line 1494
], ],
"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> }
</figure></t> ]]></sourcecode>
</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 3.4.1 of <xref target="RFC8949"></xref>). The CBOR (<xref target="RFC8949" sectionFormat="of" section="3.4.1"/>). 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 Table <dd>
3.<vspace blankLines="1" />This is a mandatory attribute.</t> <t>Status of attack mitigation. The various
possible values of 'status' parameter are explained in <xref targe
<t hangText="bytes-dropped:">The total dropped byte count for t="table3"
format="default"/>.</t>
<t>This is a mandatory attribute.</t>
</dd>
<dt>bytes-dropped:</dt>
<dd>
<t>The total dropped byte count for
the mitigation request since the attack mitigation was 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="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 was triggered. This average SHOULD be over mitigation was triggered. This average <bcp14>SHOULD</bcp14> be ov er
five-minute intervals (that is, measuring bytes into five-minute five-minute intervals (that is, measuring bytes into five-minute
buckets and then averaging these buckets over the time since the buckets 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>
</dd>
<t hangText="pkts-dropped:">The total number of dropped packet <dt>pkts-dropped:</dt>
<dd>
<t>The total number of dropped packet
count for the mitigation request since the attack mitigation was 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 was triggered. This average SHOULD be over mitigation was triggered. This average <bcp14>SHOULD</bcp14> be ov er
five-minute intervals (that is, measuring packets into five-minute intervals (that is, measuring packets into
five-minute buckets and then averaging these buckets over the five-minute buckets and then averaging these buckets over the
time since the mitigation was triggered).<vspace time since the mitigation was triggered).</t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</list></t> </dd>
</dl>
<t><figure> <table anchor="table3" align="center">
<artwork align="center"><![CDATA[+-----------+-------------------- <name>Values of 'status' Parameter</name>
--------------------------------+ <thead>
| Parameter | Description | <tr>
| Value | | <th>Parameter Value</th>
+===========+====================================================+ <th>Description</th>
| 1 | Attack mitigation setup is in progress (e.g., | </tr>
| | changing the network path to redirect the inbound | </thead>
| | traffic to a DOTS mitigator). | <tbody>
+-----------+----------------------------------------------------+ <tr>
| 2 | Attack is being successfully mitigated (e.g., | <td>1</td>
| | traffic is redirected to a DDoS mitigator and | <td>Attack mitigation setup is in progress (e.g.,
| | attack traffic is dropped). | changing the network path to redirect the inbound
+-----------+----------------------------------------------------+ traffic to a DOTS mitigator).</td>
| 3 | Attack has stopped and the DOTS client can | </tr>
| | withdraw the mitigation request. This status code | <tr>
| | will be transmitted for immediate mitigation | <td>2</td>
| | requests till the mitigation is withdrawn or the | <td>Attack is being successfully mitigated (e.g.,
| | lifetime expires. For mitigation requests with | traffic is redirected to a DDoS mitigator and
| | preconfigured scopes (i.e., 'trigger-mitigation' | attack traffic is dropped).</td>
| | set to 'false'), this status code will be | </tr>
| | transmitted four times and then transition to "8". | <tr>
+-----------+----------------------------------------------------+ <td>3</td>
| 4 | Attack has exceeded the mitigation provider | <td>Attack has stopped and the DOTS client can
| | capability. | withdraw the mitigation request. This status code
+-----------+----------------------------------------------------+ will be transmitted for immediate mitigation
| 5 | DOTS client has withdrawn the mitigation request | requests till the mitigation is withdrawn or the
| | and the mitigation is active but terminating. | lifetime expires. For mitigation requests with
+-----------+----------------------------------------------------+ preconfigured scopes (i.e., 'trigger-mitigation'
| 6 | Attack mitigation is now terminated. | set to 'false'), this status code will be
+-----------+----------------------------------------------------+ transmitted four times and then transition to '8'.</td>
| 7 | Attack mitigation is withdrawn (by the DOTS | </tr>
| | server). If a mitigation request with 'trigger- | <tr>
| | mitigation' set to 'false' is withdrawn because it | <td>4</td>
| | overlaps with an immediate mitigation request, | <td>Attack has exceeded the mitigation provider
| | this status code will be transmitted four times | capability.</td>
| | and then transition to "8" for the mitigation | </tr>
| | request with preconfigured scopes. | <tr>
+-----------+----------------------------------------------------+ <td>5</td>
| 8 | Attack mitigation will be triggered for the | <td>DOTS client has withdrawn the mitigation request
| | mitigation request only when the DOTS signal | and the mitigation is active but terminating.</td>
| | channel session is lost. | </tr>
+-----------+----------------------------------------------------+ <tr>
<td>6</td>
Table 3: Values of 'status' Parameter]]></artwork> <td>Attack mitigation is now terminated.</td>
</figure></t> </tr>
<tr>
<t></t> <td>7</td>
<td>Attack mitigation is withdrawn (by the DOTS
<section anchor="obs" title="DOTS Servers Sending Mitigation Status"> server). If a mitigation request with 'trigger-
<t>The Observe Option defined in <xref target="RFC7641"></xref> mitigation' set to 'false' is withdrawn because it
overlaps with an immediate mitigation request,
this status code will be transmitted four times
and then transition to '8' for the mitigation
request with preconfigured scopes.</td>
</tr>
<tr>
<td>8</td>
<td>Attack mitigation will be triggered for the
mitigation request only when the DOTS signal
channel session is lost.</td>
</tr>
</tbody>
</table>
<section anchor="obs" numbered="true" toc="default">
<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 support the Observe Option for resource. DOTS implementations <bcp14>MUST</bcp14> support the Obser
both 'mitigate' and 'config' (<xref ve Option 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 the 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" sectionFormat="of" se
target="RFC7641"></xref> to send a Confirmable message instead of ction="4.5"/>
to send a Confirmable message instead of
a Non-confirmable message at least every 24 hours for the a Non-confirmable message at least every 24 hours for the
following reasons: First, the DOTS signal channel uses a heartbeat following reasons: First, the DOTS signal channel uses a heartbeat
mechanism to determine if the DOTS client is alive. Second, mechanism to determine if the DOTS client is alive. Second,
Confirmable messages are not suitable during an attack.</t> Confirmable 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</bcp
3.1.3 of <xref target="RFC8085"></xref>).</t> 14> use an
even less aggressive rate whenever possible (case 2 in
<xref target="RFC8085" sectionFormat="of" section="3.1.3"/>).</t>
<t>When conflicting requests are detected, the DOTS server <t>When conflicting requests are detected, the DOTS server
enforces the corresponding policy (e.g., accept all requests, enforces the corresponding policy (e.g., accept all requests,
reject all requests, accept only one request but reject all the reject all requests, accept only one request but reject all the
others). It is assumed that this policy is supplied by the DOTS others). It is assumed that this policy is supplied by the DOTS
server administrator or that 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 a notification server 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 the 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 de-register itself by issuing a GET request that has explicitly de-register itself by issuing a GET request that has
the Token field set to the token of the observation to be canceled the 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'
(de-register). The latter is more deterministic and, thus, is (de-register). The latter is more deterministic and, thus, is
skipping to change at line 1732 skipping to change at line 1701
<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 de-register itself by issuing a GET request that has explicitly de-register itself by issuing a GET request that has
the Token field set to the token of the observation to be canceled the 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'
(de-register). 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 preconfigured 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
skipping to change at line 1770 skipping to change at line 1738
| 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" sectionForm
at="of"
section="3.1.3"/>.</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 withdraws the mitigation status. In such case, the DOTS client withdraws 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 per the tack per the
information sent by the DOTS server rather than performing its own information sent by the DOTS server rather than performing its own
detection that the attack has been mitigated. This ensures that detection that the attack has been mitigated. This ensures that
the DOTS client does not withdraw a mitigation request prematurely the DOTS client does not withdraw a mitigation request prematurely
because it is possible that the DOTS client does not sense the because it is possible that the DOTS client does not sense the
DDoS attack on its resources, but the DOTS server could be DDoS attack on its resources, but the DOTS server could be
actively mitigating the attack because the attack is not 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 '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 Table 4.</t> in the 'attack-status' parameter are described in
<xref target="table4" format="default"/>.</t>
<t><figure> <table anchor="table4" align="center">
<artwork align="center"><![CDATA[+-----------+-------------------- <name>Values of 'attack-status' Parameter</name>
-----------------+ <thead>
| Parameter | Description | <tr>
| Value | | <th>Parameter Value</th>
+===========+=====================================+ <th>Description</th>
| 1 | The DOTS client determines that it | </tr>
| | is still under attack. | </thead>
+-----------+-------------------------------------+ <tbody>
| 2 | The DOTS client determines that the | <tr>
| | attack is successfully mitigated | <td>1</td>
| | (e.g., attack traffic is not seen). | <td>The DOTS client determines that it
+-----------+-------------------------------------+ is still under attack.</td>
</tr>
Table 4: Values of 'attack-status' Parameter]]></artwork> <tr>
</figure></t> <td>2</td>
<td>The DOTS client determines that the
<t>The PUT request used for the efficacy update MUST include all the attack is successfully mitigated
(e.g., attack traffic is not seen).</td>
</tr>
</tbody>
</table>
<t>The PUT request used for the efficacy update <bcp14>MUST</bcp14> in
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" sectionFormat="of"
<t>The If-Match Option (Section 5.10.8.1 of <xref section="5.10.8.1"/>) 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 out 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 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
skipping to change at line 1847 skipping to change at line 1818
request. If UDP is used as transport, CoAP requests may arrive out 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 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 type=""><![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 1888 skipping to change at line 1858
"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></t>
<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 "/>, 5.03
uses Max-Age Option to indicate the number of seconds after which to 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 the 'cdid' parameter by DO
<t>The same considerations for manipulating 'cdid' parameter by DOTS TS
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 type=""><![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 mitigation acknowledges a DOTS client's request to withdraw the DOTS mitigation
request using 2.02 (Deleted) Response Code with no response payload. request using a 2.02 (Deleted) Response Code with no response payload.
A 2.02 (Deleted) Response Code is returned even if the 'mid' A 2.02 (Deleted) Response Code is returned even if the 'mid'
parameter value conveyed in the DELETE request does not exist in its parameter 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.</t> <bcp14>MUST</bcp14> treat the mitigation as terminated.</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 <li>Heartbeat interval ('heartbeat-interval'): DOTS agents
regularly send heartbeats to each other after mutual regularly send heartbeats to each other after mutual
authentication is successfully completed in order to keep the DOTS authentication is successfully completed in order to keep the DOTS
signal channel open. Heartbeat messages are exchanged between DOTS signal channel open. Heartbeat messages are exchanged between DOTS
agents every 'heartbeat-interval' seconds to detect the current agents every 'heartbeat-interval' seconds to detect the current
status of the DOTS signal channel session.</t> status of the DOTS signal channel session.</li>
<li>Missing heartbeats allowed ('missing-hb-allowed'): This
<t>Missing heartbeats allowed ('missing-hb-allowed'): This
variable indicates the maximum number of consecutive heartbeat variable indicates the maximum number of consecutive heartbeat
messages for which a DOTS agent did not receive a response before messages for which a DOTS agent did not receive a response before
concluding that the session is disconnected or defunct.</t> concluding 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
('max-retransmit'), retransmission timeout value ('ack-timeout'), ('max-retransmit'), retransmission timeout value ('ack-timeout'),
and other message transmission parameters for Confirmable messages and other message transmission parameters for Confirmable messages
over the DOTS signal channel.</t> over the DOTS signal 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>. CoAP retransmissions and deduplication <xref target="RFC8323" format="default "/>. CoAP
over reliable transports does not support Confirmable or over reliable transports does not support Confirmable or
Non-confirmable message types. As such, the transmission-related 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), values related to 'idle-config' 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 values related to 'idle-config' to values related to switches from values related to 'idle-config' to values related to
'mitigating-config').</t> '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" sectionFormat="of" sect
target="RFC7252"></xref>, a Confirmable message is retransmitted using ion="2.1"/>,
a default timeout and exponential backoff between retransmissions, a Confirmable message is retransmitted using
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 sectionFormat="of" section="4.8"/>. The DOTS server can either piggyback
target="RFC7252"></xref>. The DOTS server can either piggyback the 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" sectionFormat="of" sect
target="RFC7252"></xref>. When the response is ready, the server sends ion="2.2"/>. When the response is ready, the server sends
it in a new Confirmable message, which, in turn, needs to be it in a new Confirmable message, which, in turn, needs to be
acknowledged by the DOTS client (see Sections 5.2.1 and 5.2.2 of <xref acknowledged by the DOTS client (see Sections <xref target="RFC7252" sec
target="RFC7252"></xref>). Requests and responses exchanged between tion="5.2.1"
sectionFormat="bare"/> and <xref target="RFC7252" section="5.2.2" section
Format="bare"/>
of <xref target="RFC7252" format="default"/>). Requests and responses exc
hanged between
DOTS agents during 'idle' time, except heartbeat messages, are marked DOTS agents during 'idle' time, except heartbeat messages, are marked
as Confirmable messages.</t> as Confirmable messages.</t>
<aside>
<figure> <t>Implementation Note: A DOTS client that receives a response in
<artwork><![CDATA[ | Implementation Note: A DOTS client that rec a Confirmable message may want to clean up the message state
eives a response in right after sending the ACK. If that ACK is lost and the DOTS
| a Confirmable message may want to clean up the message state server retransmits the Confirmable message, the DOTS client may
| right after sending the ACK. If that ACK is lost and the DOTS no longer have any state that would help it correlate this
| server retransmits the Confirmable message, the DOTS client may response; from the DOTS client's standpoint, the retransmission
| no longer have any state that would help it correlate this message is unexpected. The DOTS client will send a Reset
| response: from the DOTS client's standpoint, the retransmission message so it does not receive any more retransmissions. This
| message is unexpected. The DOTS client will send a Reset behavior is normal and not an indication of an error (see
| message so it does not receive any more retransmissions. This <xref target="RFC7252" section="5.3.2" sectionFormat="of"/> for more det
| behavior is normal and not an indication of an error (see ails).</t>
| Section 5.3.2 of [RFC7252] for more details).]]></artwork> </aside>
</figure> <section anchor="discovery" numbered="true" toc="default">
<name>Discover Configuration Parameters</name>
<section anchor="discovery" title="Discover Configuration Parameters">
<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 type=""><![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 type=""><![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 2149 skipping to change at line 2098
"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> }
</figure></t> ]]></sourcecode>
</figure>
<t>The parameters in <xref target="Figure19"></xref> are described <t>The parameters in <xref target="Figure19" format="default"/> are de
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, in <dt>probing-rate:</dt>
<dd>
<t>The average data rate, in
bytes/second, that must not be exceeded by a DOTS agent in bytes/second, that must not be exceeded by a DOTS agent in
sending to a peer DOTS agent that does not respond (referred sending to a peer DOTS agent that does not respond (referred
to as PROBING_RATE parameter in CoAP). <vspace to as PROBING_RATE parameter in CoAP). </t>
blankLines="1" />This is an optional attribute.</t> <t>This is an 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 type=""><![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 2272 skipping to change at line 2239
"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> }
</figure></t> ]]></sourcecode>
</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"/> a
<t>A PUT request (Figures <xref format="counter" nd <xref format="counter" target="Figure13a"/>) is used to convey the configurat
target="Figure13"></xref> and <xref format="counter" ion
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" sectionFormat="of" section="4.8"/>.
RECOMMENDED values of transmission parameter values are The
<bcp14>RECOMMENDED</bcp14> values of transmission parameter values are
'ack-timeout' (2 seconds), 'max-retransmit' (3), and 'ack-timeout' (2 seconds), 'max-retransmit' (3), and
'ack-random-factor' (1.5). In addition to those parameters, the 'ack-random-factor' (1.5). In addition to those parameters, the
RECOMMENDED specific DOTS transmission parameter values are <bcp14>RECOMMENDED</bcp14> specific DOTS transmission parameter values are
'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15).</t> 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15).</t>
<aside>
<t>Note: 'heartbeat-interval' should be tweaked to also assist
DOTS messages for NAT traversal (SIG-011 of <xref target="RFC8612" forma
t="default"/>).
According to <xref target="RFC8085" format="default"/>, heartbeat messag
es must not be
sent
more frequently than once every 15 seconds and should use
longer intervals when possible. Furthermore, <xref target="RFC4787" for
mat="default"/>
recommends that NATs use a state timeout of 2 minutes or
longer, but experience shows that sending packets every 15 to
30 seconds is necessary to prevent the majority of middleboxes
from losing state for UDP flows. From that standpoint, the
<bcp14>RECOMMENDED</bcp14> minimum 'heartbeat-interval' is 15 seconds an
d the
<bcp14>RECOMMENDED</bcp14> maximum 'heartbeat-interval' is 240 seconds.
The
recommended value of 30 seconds is selected to anticipate the
expiry of NAT state.</t>
<figure> <t>A 'heartbeat-interval' of 30 seconds may be considered to be
<artwork><![CDATA[ | Note: 'heartbeat-interval' should be twea too chatty in some deployments. For such deployments, DOTS
ked to also assist agents may negotiate longer 'heartbeat-interval' values to
| DOTS messages for NAT traversal (SIG-011 of [RFC8612]). prevent any network overload with too frequent heartbeats.</t>
| According to [RFC8085], heartbeat messages must not be sent
| more frequently than once every 15 seconds and should use
| longer intervals when possible. Furthermore, [RFC4787]
| recommends that NATs use a state timeout of 2 minutes or
| longer, but experience shows that sending packets every 15 to
| 30 seconds is necessary to prevent the majority of middleboxes
| from losing state for UDP flows. From that standpoint, the
| RECOMMENDED minimum 'heartbeat-interval' is 15 seconds and the
| RECOMMENDED maximum 'heartbeat-interval' is 240 seconds. The
| recommended value of 30 seconds is selected to anticipate the
| expiry of NAT state.
|
| A 'heartbeat-interval' of 30 seconds may be considered to be
| too chatty in some deployments. For such deployments, DOTS
| agents may negotiate longer 'heartbeat-interval' values to
| prevent any network overload with too frequent heartbeats.
|
| Different heartbeat intervals can be defined for 'mitigating-
| config' and 'idle-config' to reduce being too chatty during
| idle times. If there is an on-path translator between the DOTS
| client (standalone or part of a DOTS gateway) and the DOTS
| server, the 'mitigating-config' 'heartbeat-interval' has to be
| smaller than the translator session timeout. It is recommended
| that the 'idle-config' 'heartbeat-interval' also be smaller
| than the translator session timeout to prevent translator
| traversal issues or that it be disabled entirely. Means to
| discover the lifetime assigned by a translator are out of
| scope.
|
| Given that the size of the heartbeat request cannot exceed
| ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate'
| should be set appropriately to avoid slowing down heartbeat
| exchanges. For example, 'probing-rate' may be set to 2 *
| ("size of encrypted DOTS heartbeat request"/'heartbeat-
| interval') or (("size of encrypted DOTS heartbeat request" +
| "average size of an encrypted mitigation request")/'heartbeat-
| interval'). Absent any explicit configuration or inability to
| dynamically adjust 'probing-rate' values (Section 4.8.1 of
| [RFC7252]), DOTS agents use 5 bytes/second as a default
| 'probing-rate' value.]]></artwork>
</figure>
<t>Different heartbeat intervals can be defined for 'mitigating-
config' and 'idle-config' to reduce being too chatty during
idle times. If there is an on-path translator between the DOTS
client (standalone or part of a DOTS gateway) and the DOTS
server, the 'mitigating-config' 'heartbeat-interval' has to be
smaller than the translator session timeout. It is recommended
that the 'idle-config' 'heartbeat-interval' also be smaller
than the translator session timeout to prevent translator
traversal issues or that it be disabled entirely. Means to
discover the lifetime assigned by a translator are out of
scope.</t>
<t>Given that the size of the heartbeat request cannot exceed
('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate'
should be set appropriately to avoid slowing down heartbeat
exchanges. For example, 'probing-rate' may be set to 2 *
("size of encrypted DOTS heartbeat request"/'heartbeat-
interval') or (("size of encrypted DOTS heartbeat request" +
"average size of an encrypted mitigation request")/'heartbeat-
interval'). Absent any explicit configuration or inability to
dynamically adjust 'probing-rate' values (<xref target="RFC7252" section
Format="of"
section="4.8.1"/>), DOTS agents use 5 bytes/second as a default
'probing-rate' value.</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" sectionFormat="of" section="4.8.1"/>.
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 type=""><![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 Table 1 is <t>The additional Uri-Path parameter to those defined in
as follows: <list hangIndent="5" style="hanging"> <xref target="table1" format="default"/> is as follows: </t>
<t hangText="sid:">Session Identifier is an identifier for the <dl newline="false" spacing="normal" indent="6">
<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 type=""><![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 2416 skipping to change at line 2384
"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 (<xref target="Figur
target="Figure13a"></xref>) is defined in <xref e13a" format="default"/>) is defined in <xref target="discovery" format="default
target="discovery"></xref>.</t> "/>.</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. A request 'mitigating-config' and 'idle-config' in a PUT request. A request
does not need to include both 'mitigating-config' and 'idle-config' does not need to include both 'mitigating-config' and 'idle-config'
attributes.</t> attributes.</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. That is, the configuration request with a lower numeric 'sid' value. That is, the configuration
parameters that are included in the PUT request with a higher parameters that are included in the PUT request with a higher
numeric 'sid' value will be used instead of the DOTS server's numeric 'sid' value will be used instead of the DOTS server's
defaults. To avoid maintaining a long list of 'sid' requests from a defaults. To avoid maintaining a long list of 'sid' requests from a
DOTS client, the lower numeric 'sid' MUST be automatically deleted DOTS client, the lower numeric 'sid' <bcp14>MUST</bcp14> be automatica lly deleted
and no longer available at the DOTS server.</t> and no longer available at the 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 type=""><![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 2494 skipping to change at line 2457
"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
overy"
format="default"/>).</t>
<t>The DOTS
client may retry and send the PUT request with updated attribute client may retry and send the PUT request with updated attribute
values acceptable to the DOTS server.</t> values acceptable to the DOTS server.</t>
</list></t> </li>
</ul>
<t>A DOTS client may issue a GET message for 'config' with a 'sid' <t>A DOTS client may issue a GET message for 'config' with a 'sid'
Uri-Path parameter to retrieve the negotiated configuration. The Uri-Path parameter to retrieve the negotiated configuration. The
response does not need to include 'sid' in its message body.</t> response does not need to include 'sid' in its message body.</t>
</section> </section>
<section anchor="update" numbered="true" toc="default">
<section anchor="update" <name>Configuration Freshness and Notifications</name>
title="Configuration Freshness and Notifications"> <t>Max-Age Option (<xref target="RFC7252" sectionFormat="of" section="
<t>Max-Age Option (Section 5.10.5 of <xref target="RFC7252"></xref>) 5.10.5"/>)
SHOULD be returned by a DOTS server to associate a validity time <bcp14>SHOULD</bcp14> be returned by a DOTS server to associate a vali
dity time
with a configuration it sends. This feature forces the client to with a configuration it sends. This feature forces the client to
retrieve the updated configuration data if a change occurs at the retrieve the updated configuration data if a change occurs at the
DOTS server side. For example, the new configuration may instruct a DOTS server side. For example, the new configuration may instruct a
DOTS client to cease heartbeats or reduce heartbeat frequency.</t> DOTS client to cease 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
<t>Returning a Max-Age Option set to 2^(32)-1 is equivalent to 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 a 'sid' Uri-Path parameter 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 to retrieve the current and acceptable configuration before the
expiry of the value enclosed in the Max-Age Option. This request is expiry of the value enclosed in the Max-Age Option. This request is
considered by the client and the server to be 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 is active, refresh requests <bcp14>MUST NOT</bcp14> be sent by DOTS cl
the DOTS server MUST NOT terminate the (D)TLS session after the ients, and
the DOTS server <bcp14>MUST NOT</bcp14> terminate the (D)TLS session a
fter the
expiry of the value returned in Max-Age Option.</t> expiry 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" sectionFormat="of" section="5.10.5"
prevent such overload, it is RECOMMENDED that DOTS servers return a />). 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 a 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" sectionFormat="of" section="4.2"/>).</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 to 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" sectionFormat="of" section="6"/>)).</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 type=""><![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 a 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="RFC8811"></xref>.</t> <xref target="RFC8811" sectionFormat="of" section="3.2.2"/>.</t>
<t>To redirect a DOTS client to an alternative DOTS server, the DOTS <t>To redirect a DOTS client to an alternative DOTS server, the DOTS
server can return the error Response Code 5.03 (Service Unavailable) server can return the error Response Code 5.03 (Service Unavailable)
in response to a request from the DOTS client or convey the error in response to a request from the DOTS client or convey the error
Response Code 5.03 in a unidirectional notification response to the Response Code 5.03 in a unidirectional notification response to the
client.</t> client.</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 type=""><![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>This is a mandatory attribute.</t>
<t hangText="alt-server-record:">A list of IP addresses of an </dd>
alternate DOTS server.<vspace blankLines="1" />This is an optional <dt>alt-server-record:</dt>
attribute.</t> <dd>
</list></t> <t>A list of IP addresses of an
alternate DOTS server.</t>
<t>This is an optional attribute.</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 Max- 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 TTL. Age Option set to 2<sup>(32)</sup>-1 is equivalent to receiving an infin ite TTL.
This value means that the alternate DOTS server is to be used until This value means that the alternate DOTS server is to be used until
the alternate DOTS server redirects the traffic with another 5.03 the alternate DOTS server redirects the traffic with another 5.03
response that conveys an alternate server's FQDN.</t> 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 a 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 fallback 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 that 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 redirect
messages MAY be rejected by DOTS servers.</t> messages <bcp14>MAY</bcp14> 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 type=""><![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 a 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 to have failed, but server included, it considers the current request to have failed, but
it SHOULD try resending the request to the alternate DOTS server. it <bcp14>SHOULD</bcp14> try resending the request to the alternate DOTS server.
During a DDoS attack, the DNS server may be the target of another DDoS During a DDoS attack, the DNS server may be the target of another DDoS
attack, the 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 the DNS lookup of the alternate 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 DOTS 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 (<xref or a TCP session with the alternate DOTS server (<xref target="HE" forma
target="HE"></xref>). Note that state synchronization (e.g., signal t="default"/>). Note that state synchronization (e.g., signal
session configuration, aliases) is assumed to be in place between the session configuration, aliases) is assumed to be in place between the
original and alternate DOTS servers; such synchronization means are original and alternate DOTS servers; such synchronization means are
out of scope. If session configuration refresh is needed while out of scope. If session configuration refresh is needed while
redirection is in place, the DOTS client follows the procedure defined redirection is in place, the DOTS client follows the procedure defined
in <xref target="update"></xref>. In 'idle' time and under some in <xref target="update" format="default"/>. In 'idle' time and under so me
conditions (e.g., infinite configuration lifetime, infinite conditions (e.g., infinite configuration lifetime, infinite
redirection TTL, and failure to refresh the configuration), the DOTS redirection TTL, and failure to refresh the configuration), the DOTS
client follows the procedure defined in <xref target="convey"></xref> client follows the procedure defined in <xref target="convey" format="de fault"/>
to negotiate the DOTS signal channel session configuration with the to negotiate the DOTS signal channel session configuration with the
alternate server. The DOTS client MAY implement a method to construct alternate server. The DOTS client <bcp14>MAY</bcp14> implement a method
IPv4-embedded IPv6 addresses <xref target="RFC6052"></xref>; this is to construct
IPv4-embedded IPv6 addresses <xref target="RFC6052" format="default"/>;
this is
required to handle the scenario where an IPv6-only DOTS client required to handle the scenario where an IPv6-only DOTS client
communicates with an IPv4-only alternate DOTS server.</t> communicates with an IPv4-only alternate DOTS server.</t>
<t>If the DOTS client has been redirected to a DOTS server with which <t>If the DOTS client has been redirected to a DOTS server with which
it has already communicated within the last five (5) minutes, it MUST it has already communicated within the last five (5) minutes, it <bcp14> MUST</bcp14>
ignore the redirection and try to contact other DOTS servers listed in ignore the redirection and try to contact other DOTS servers listed in
the local configuration or discovered using dynamic means such as DHCP the local configuration or discovered using dynamic means, such as DHCP
or SRV procedures <xref target="RFC8973"></xref>. It is RECOMMENDED or SRV procedures <xref target="RFC8973" format="default"/>. It is <bcp1
4>RECOMMENDED</bcp14>
that DOTS clients support the means to alert administrators about that DOTS clients support the means to alert administrators about
redirect loops.</t> redirect 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 to distinguish an <t>To provide an indication of signal health and to distinguish an
'idle' signal channel from a 'disconnected' or 'defunct' session, the 'idle' signal channel from a 'disconnected' or 'defunct' session, the
DOTS agent sends a heartbeat over the signal channel to maintain its DOTS agent sends a heartbeat over the signal channel to maintain its
half of the channel (also, aligned with the "consents" recommendation half of the channel (also, aligned with the "consents" recommendation
in Section 6 of <xref target="RFC8085"></xref>). The DOTS agent in <xref target="RFC8085" sectionFormat="of" section="6"/>). The DOTS ag ent
similarly expects a heartbeat from its peer DOTS agent, and it may similarly expects a heartbeat from its peer DOTS agent, and it may
consider a session terminated in the prolonged absence of a peer agent consider a session terminated in the prolonged absence of a peer agent
heartbeat. Concretely, while the communication between the DOTS agents heartbeat. Concretely, while the communication between the DOTS agents
is otherwise quiescent, the DOTS client will probe the DOTS server to is 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. Such
probes can also keep the bindings of firewalls and/or stateful probes can also keep the bindings of firewalls and/or stateful
translators alive. This probing reduces the frequency of establishing translators alive. This probing reduces the frequency of establishing
a new handshake when a DOTS signal needs to be conveyed to the DOTS a new handshake when a DOTS signal needs to be conveyed to the DOTS
server.</t> server.</t>
<aside>
<figure> <t>Implementation Note: Given that CoAP roles can be multiplexed
<artwork><![CDATA[ | Implementation Note: Given that CoAP roles over the same session as discussed in [RFC7252] and are already
can be multiplexed supported by CoAP implementations, both the DOTS client and
| over the same session as discussed in [RFC7252] and are already server can send DOTS heartbeat requests.</t>
| supported by CoAP implementations, both the DOTS client and </aside>
| server can send DOTS heartbeat requests.]]></artwork>
</figure>
<t>The DOTS heartbeat mechanism uses Non-confirmable PUT requests <t>The DOTS heartbeat mechanism uses Non-confirmable PUT requests
(<xref target="hbreq"></xref>) with an expected 2.04 (Changed) (<xref target="hbreq" format="default"/>) 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 type=""><![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 indicate that a DOTS agent is (or is not) receiving 'false') to indicate that a DOTS agent is (or is not) receiving
heartbeat messages from its peer in the last (2 * 'heartbeat- heartbeat messages from its peer in the last (2 * 'heartbeat-
interval') period. Such information can be used by a peer DOTS agent interval') period. Such information can be used by a peer DOTS agent
to detect or confirm connectivity issues and react accordingly. For to detect or confirm connectivity issues and react accordingly. For
example, if a DOTS client receives a 2.04 response for its heartbeat example, if a DOTS client receives a 2.04 response for its heartbeat
messages but no server-initiated heartbeat messages, the DOTS client messages but no server-initiated heartbeat messages, the DOTS client
sets 'peer-hb-status' to 'false' in its next heartbeat message. Upon sets 'peer-hb-status' to 'false' in its next heartbeat message. Upon
receipt of this message, the DOTS server then will need to try another receipt of this message, the DOTS server then will need to try another
strategy for sending the heartbeats (e.g., adjust the heartbeat strategy for sending the heartbeats (e.g., adjust the heartbeat
interval or send a server-initiated heartbeat immediately after interval or send a server-initiated heartbeat immediately after
receiving a client-initiated heartbeat message).</t> receiving a client-initiated heartbeat message).</t>
<figure anchor="hbrep">
<t><figure anchor="hbrep" <name>Response to a DOTS Heartbeat Request (with an Empty Body)</name>
title="Response to a DOTS Heartbeat Request (with an Empty Body)"> <sourcecode type=""><![CDATA[
<artwork><![CDATA[ Header: (Code=2.04) Header: (Code=2.04)
]]></sourcecode>
]]></artwork> </figure>
</figure></t> <t>DOTS servers <bcp14>MAY</bcp14> trigger their heartbeat requests imme
diately after
<t>DOTS servers MAY trigger their heartbeat requests immediately after
receiving heartbeat probes from peer DOTS clients. It is the receiving heartbeat probes from peer DOTS clients. It is the
responsibility of DOTS clients to ensure that on-path 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 reestablish the DOTS signal channel DOTS client <bcp14>MUST</bcp14> then try to reestablish the DOTS signal channel
session, preferably by resuming the (D)TLS session.</t> session, preferably by resuming the (D)TLS session.</t>
<aside>
<figure align="center"> <t>Note: If a new DOTS signal channel session cannot be
<artwork align="center"><![CDATA[ | Note: If a new DOTS signal chann established, the DOTS client <bcp14>SHOULD NOT</bcp14> retry to establish th
el session cannot be e
| established, the DOTS client SHOULD NOT retry to establish the DOTS signal channel session more frequently than every 300
| DOTS signal channel session more frequently than every 300 seconds (5 minutes) and <bcp14>MUST NOT</bcp14> retry more frequently than
| seconds (5 minutes) and MUST NOT retry more frequently than every 60 seconds (1 minute). It is recommended that DOTS
| every 60 seconds (1 minute). It is recommended that DOTS clients support the means to alert administrators about the
| clients support the means to alert administrators about the failure to establish a (D)TLS session.</t>
| failure to establish a (D)TLS session.]]></artwork> </aside>
</figure>
<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>
<t indent="5">The DOTS client <bcp14>MUST NOT</bcp14> consider the D
<t><list style="empty"> OTS signal channel
<t>The DOTS client MUST NOT 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 indent="5">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 indent="5">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>
<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 the 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 NOT</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 that the channel session. In this case, the DOTS server can identify that the
DOTS client is under attack and that the inbound link to the DOTS DOTS client is under attack and that the inbound link to the DOTS
client (domain) is saturated. Furthermore, if the DOTS server does not client (domain) is saturated. Furthermore, if the DOTS server does not
receive a mitigation request from the DOTS client, it implies that the receive a mitigation request from the DOTS client, it implies that the
DOTS client has not detected the attack or, if an attack mitigation is DOTS client has not detected the attack or, if an attack mitigation is
in progress, it implies that the applied DDoS mitigation actions are in progress, it implies that the applied DDoS mitigation actions are
not yet effectively handling the DDoS attack volume.</t> not yet 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 preconfigured 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 module <xref target="RFC7950"></xref> <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 is not intended to be used via NETCONF/RESTCONF for <t>This YANG module is not intended to be used via NETCONF/RESTCONF for
DOTS server management purposes; such a module is out of the scope of DOTS server management purposes; such a module is out of the scope of
this document. It serves only to provide abstract data structures. This this document. It serves only to provide abstract data structures. This
document uses the "structure" extension specified in <xref document uses the "structure" extension specified in <xref target="RFC8791
target="RFC8791"></xref>.</t> " format="default"/>.</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 anchor="tree" numbered="true" toc="default">
<section anchor="tree" 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",
which has the following tree structure. A DOTS signal message can be a which has the following tree structure. A DOTS signal message can be a
mitigation, a configuration, a redirect, or a heartbeat message.</t> mitigation, a configuration, a redirect, or a heartbeat message.</t>
<t>This tree structure obsoletes the one described in
<t>This tree structure obsoletes the one described in Section 5.1 of <xref target="RFC8782" sectionFormat="of" section="5.1"/>.</t>
<xref target="RFC8782"></xref>.</t> <sourcecode type="yangtree"><![CDATA[
module: ietf-dots-signal-channel
<t><figure align="center">
<artwork align="center"><![CDATA[module: ietf-dots-signal-channel
structure dots-signal: structure dots-signal:
+-- (message-type)? +-- (message-type)?
+--:(mitigation-scope) +--:(mitigation-scope)
| +-- scope* [] | +-- scope* []
| +-- target-prefix* inet:ip-prefix | +-- target-prefix* inet:ip-prefix
| +-- target-port-range* [lower-port] | +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number | | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number | | +-- upper-port? inet:port-number
| +-- target-protocol* uint8 | +-- target-protocol* uint8
skipping to change at line 3019 skipping to change at line 2947
| | +-- max-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | +-- current-value-decimal? decimal64
+--:(redirected-signal) +--:(redirected-signal)
| +-- (direction)? | +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- alt-server inet:domain-name | +-- alt-server inet:domain-name
| +-- alt-server-record* inet:ip-address | +-- alt-server-record* inet:ip-address
+--:(heartbeat) +--:(heartbeat)
+-- peer-hb-status boolean +-- peer-hb-status boolean
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section anchor="iana-yang" numbered="true" toc="default">
<name>IANA DOTS Signal Channel YANG Module</name>
<t>This version obsoletes the version described in
<xref target="RFC8782" sectionFormat="of" section="5.2"/>.</t>
<sourcecode name="iana-dots-signal-channel@2021-08-16.yang" type="yang"
markers="true"><![CDATA[
<section anchor="iana-yang" title="IANA DOTS Signal Channel YANG Module">
<t>This version obsoletes the version described in Section 5.2 of
<xref target="RFC8782"></xref>.</t>
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "iana-dots-signal-channel@2020-
09-24.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-dots-signal; prefix iana-dots-signal;
organization organization
"IANA"; "IANA";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
skipping to change at line 3059 skipping to change at line 2985
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2021 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 8782; see This version of this YANG module is part of RFC 9132; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-09-24 { revision 2021-08-16 {
description description
"Updated the prefix used for the module."; "Updated the prefix used for the module.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
revision 2020-05-28 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8782: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
skipping to change at line 3092 skipping to change at line 3018
description description
"Attack mitigation setup is in progress (e.g., changing "Attack mitigation setup is in progress (e.g., changing
the network path to reroute 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).";
} }
enum attack-stopped { enum attack-stopped {
value 3; value 3;
description description
"Attack has stopped and the DOTS client can "Attack has stopped and the DOTS client can
withdraw the mitigation request."; withdraw the mitigation request.";
} }
enum attack-exceeded-capability { enum attack-exceeded-capability {
value 4; value 4;
description description
skipping to change at line 3140 skipping to change at line 3066
} }
description description
"Enumeration for status reported by the DOTS server."; "Enumeration for status reported by the DOTS server.";
} }
typedef conflict-status { typedef conflict-status {
type enumeration { type enumeration {
enum request-inactive-other-active { enum request-inactive-other-active {
value 1; value 1;
description description
"DOTS Server has detected conflicting mitigation "DOTS server has detected conflicting mitigation
requests from different DOTS clients. requests from different DOTS clients.
This mitigation request is currently inactive This mitigation request is currently inactive
until the conflicts are resolved. Another until the conflicts are resolved. Another
mitigation request is active."; mitigation request is active.";
} }
enum request-active { enum request-active {
value 2; value 2;
description description
"DOTS Server has detected conflicting mitigation "DOTS server has detected conflicting mitigation
requests from different DOTS clients. requests from different DOTS clients.
This mitigation request is currently active."; This mitigation request is currently active.";
} }
enum all-requests-inactive { enum all-requests-inactive {
value 3; value 3;
description description
"DOTS Server has detected conflicting mitigation "DOTS server has detected conflicting mitigation
requests from different DOTS clients. All requests from different DOTS clients. All
conflicting mitigation requests are inactive."; conflicting mitigation requests are inactive.";
} }
} }
description description
"Enumeration for conflict status."; "Enumeration for conflict status.";
} }
typedef conflict-cause { typedef conflict-cause {
type enumeration { type enumeration {
skipping to change at line 3213 skipping to change at line 3139
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="defau
lt"/>.</t>
<t>This version obsoletes the version described in
<xref target="RFC8782" sectionFormat="of" section="5.3"/>.</t>
<sourcecode name="ietf-dots-signal-channel@2021-08-16.yang" type="yang"
markers="true"><![CDATA[
<section anchor="yrequest" title="IETF DOTS Signal Channel YANG Module">
<t>This module uses the common YANG types defined in <xref
target="RFC6991"></xref> and types defined in <xref
target="RFC8783"></xref>.</t>
<t>This version obsoletes the version described in Section 5.3 of
<xref target="RFC8782"></xref>.</t>
<t><figure align="center">
<artwork align="center"><![CDATA[<CODE BEGINS> file "ietf-dots-signa
l-channel@2021-03-02.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 dots-signal; prefix dots-signal;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
} }
skipping to change at line 3251 skipping to change at line 3172
} }
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix data-channel; prefix data-channel;
reference reference
"RFC 8783: 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-dots-signal; prefix iana-dots-signal;
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat Signaling "RFC 9132: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification"; (DOTS) Signal Channel Specification";
} }
import ietf-yang-structure-ext { import ietf-yang-structure-ext {
prefix sx; prefix sx;
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
skipping to change at line 3273 skipping to change at line 3194
"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: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Editor: Jon Shallow Editor: Jon Shallow
<mailto:supjps-ietf@jpshallow.com> <mailto:supjps-ietf@jpshallow.com>
Author: Konda, Tirumaleswar Reddy.K Author: Konda, Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:mailto:kondtir@gmail.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@ironmountain.co.uk>"; <mailto:nteague@ironmountain.co.uk>";
description description
skipping to change at line 3297 skipping to change at line 3218
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2021 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 9132; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2021-03-02 { revision 2021-08-16 {
description description
"Updated revision to comply with RFC8791. "Updated revision to comply with RFC 8791.
This version is not backward compatible with the version This version is not backward compatible with the version
published in RFC 8782."; published in RFC 8782.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
revision 2020-05-28 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8782: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
skipping to change at line 3389 skipping to change at line 3310
This identifier must be unique for each mitigation This identifier must be unique for each mitigation
request bound to the DOTS client."; request bound to the DOTS client.";
} }
leaf mitigation-start { leaf mitigation-start {
type uint64; type uint64;
description description
"Mitigation start time is represented in seconds "Mitigation start time is represented in seconds
relative to 1970-01-01T00:00:00Z in UTC time. relative to 1970-01-01T00:00:00Z in UTC time.
This is a mandatory attribute when an attack mitigation This is a mandatory attribute when an attack
is active. It must not be returned for a mitigation is active. It must not be returned for
mitigation with 'status' code set to 8."; a mitigation with 'status' code set to 8.";
} }
leaf status { leaf status {
type iana-dots-signal:status; type iana-dots-signal:status;
description description
"Indicates the status of a mitigation request. "Indicates the status of a mitigation request.
It must be included in responses only. It must be included in responses only.
This is a mandatory attribute if a mitigation This is a mandatory attribute if a mitigation
request is accepted and processed by the server."; request is accepted and processed by the server.";
} }
skipping to change at line 3420 skipping to change at line 3341
leaf conflict-cause { leaf conflict-cause {
type iana-dots-signal:conflict-cause; type iana-dots-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 resend 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
this timer."; of 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 data-channel:target { uses data-channel:target {
when "/dots-signal/scope/conflict-information/" when "/dots-signal/scope/conflict-information/"
+ "conflict-cause = 'overlapping-targets'"; + "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 =" when "../../conflict-cause ="
+ " 'conflict-with-acceptlist'"; + " 'conflict-with-acceptlist'";
key "acl-name"; key "acl-name";
description description
"List of conflicting ACLs as defined in the DOTS data "List of conflicting ACLs, as defined in the DOTS
channel. These ACLs are uniquely defined by data channel. These ACLs are uniquely defined by
cuid and acl-name."; cuid and acl-name.";
leaf acl-name { leaf acl-name {
type leafref { type leafref {
path "/data-channel:dots-data" path "/data-channel:dots-data"
+ "/data-channel:dots-client/data-channel:acls" + "/data-channel:dots-client"
+ "/data-channel:acls"
+ "/data-channel:acl/data-channel:name"; + "/data-channel:acl/data-channel:name";
} }
description description
"Reference to the conflicting ACL name bound to "Reference to the conflicting ACL name bound to
a DOTS client."; a DOTS client.";
} }
leaf acl-type { leaf acl-type {
type leafref { type leafref {
path "/data-channel:dots-data" path "/data-channel:dots-data"
+ "/data-channel:dots-client/data-channel:acls" + "/data-channel:dots-client"
+ "/data-channel:acls"
+ "/data-channel:acl/data-channel:type"; + "/data-channel:acl/data-channel:type";
} }
description description
"Reference to the conflicting ACL type bound to "Reference to the conflicting ACL type bound to
a DOTS client."; a DOTS client.";
} }
} }
leaf mid { leaf mid {
when "../../conflict-cause = 'overlapping-targets'"; when "../../conflict-cause = 'overlapping-targets'";
type uint32; type uint32;
skipping to change at line 3480 skipping to change at line 3404
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";
description description
"The total dropped byte count for the mitigation "The total dropped byte count for the mitigation
request since the attack mitigation was 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
of counter64 for dropped bytes."; value of counter64 for dropped bytes.";
} }
leaf bps-dropped { leaf bps-dropped {
type yang:gauge64; type yang:gauge64;
units "bytes per second"; units "bytes per second";
description description
"The average number of dropped bytes per second for "The average number of dropped bytes per second for
the mitigation request since the attack the mitigation request since the attack
mitigation was 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
skipping to change at line 3836 skipping to change at line 3760
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> ]]></sourcecode>
]]></artwork>
</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 5 and are assigned an integer key cp14> be
to save space. <list style="empty"> mapped to CBOR types, as shown in <xref target="table5" format="default"/>
<t>Note: Implementers must check that the mapping output provided by , and are
assigned an integer key to save space. </t>
<t indent="3">Note: Implementers must check that the mapping output prov
ided 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 5. For example, some CBOR and JSON types for enumerations and <xref target="table5" format="default"/>. For example, some CBOR and
JSON types for enumerations and
the 64-bit quantities can differ depending on the encoder used.</t> the 64-bit quantities can differ depending on the encoder used.</t>
</list></t>
<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 they 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="table5" align="center">
<t><figure> <name>CBOR Key Values Used in DOTS Signal Channel Messages &amp; Their Mapping
<artwork><![CDATA[+---------------------+--------------+------+------- s to JSON and YANG</name>
------+--------+ <thead>
| Parameter Name | YANG Type | CBOR | CBOR Major | JSON | <tr>
| | | Key | Type & | Type | <th>Parameter Name</th>
| | | | Information | | <th>YANG Type</th>
+=====================+==============+======+=============+========+ <th>CBOR Key</th>
| ietf-dots-signal- | container | 1 | 5 map | Object | <th>CBOR Major Type &amp; Information</th>
| channel:mitigation- | | | | | <th>JSON Type</th>
| scope | | | | | </tr>
+---------------------+--------------+------+-------------+--------+ </thead>
| scope | list | 2 | 4 array | Array | <tbody>
+---------------------+--------------+------+-------------+--------+ <tr>
| cdid | string | 3 | 3 text | String | <td> ietf-dots-signal-channel:mitigation-scope</td>
| | | | string | | <td>container</td>
+---------------------+--------------+------+-------------+--------+ <td>1</td>
| cuid | string | 4 | 3 text | String | <td>5 map</td>
| | | | string | | <td>Object</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| mid | uint32 | 5 | 0 unsigned | Number | <tr>
+---------------------+--------------+------+-------------+--------+ <td>scope</td>
| target-prefix | leaf-list | 6 | 4 array | Array | <td>list</td>
| +--------------+------+-------------+--------+ <td>2</td>
| | inet:ip- | | 3 text | String | <td>4 array</td>
| | prefix | | string | | <td>Array</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| target-port-range | list | 7 | 4 array | Array | <tr>
+---------------------+--------------+------+-------------+--------+ <td>cdid</td>
| lower-port | inet:port- | 8 | 0 unsigned | Number | <td>string</td>
| | number | | | | <td>3</td>
+---------------------+--------------+------+-------------+--------+ <td>3 text string</td>
| upper-port | inet:port- | 9 | 0 unsigned | Number | <td>String</td>
| | number | | | | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| target-protocol | leaf-list | 10 | 4 array | Array | <td>cuid</td>
| +--------------+------+-------------+--------+ <td>string</td>
| | uint8 | | 0 unsigned | Number | <td>4</td>
+---------------------+--------------+------+-------------+--------+ <td>3 text string</td>
| target-fqdn | leaf-list | 11 | 4 array | Array | <td>String</td>
| +--------------+------+-------------+--------+ </tr>
| | inet:domain- | | 3 text | String | <tr>
| | name | | string | | <td>mid</td>
+---------------------+--------------+------+-------------+--------+ <td>uint32</td>
| target-uri | leaf-list | 12 | 4 array | Array | <td>5</td>
| +--------------+------+-------------+--------+ <td>0 unsigned</td>
| | inet:uri | | 3 text | String | <td>Number</td>
| | | | string | | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| alias-name | leaf-list | 13 | 4 array | Array | <td rowspan="2">target-prefix</td>
| +--------------+------+-------------+--------+ <td>leaf-list</td>
| | string | | 3 text | String | <td>6</td>
| | | | string | | <td>4 array</td>
+---------------------+--------------+------+-------------+--------+ <td>Array</td>
| lifetime | union | 14 | 0 unsigned | Number | </tr>
| | | +-------------+--------+ <tr>
| | | | 1 negative | Number | <td>inet:ip-prefix</td>
+---------------------+--------------+------+-------------+--------+ <td></td>
| mitigation-start | uint64 | 15 | 0 unsigned | String | <td>3 text string</td>
+---------------------+--------------+------+-------------+--------+ <td>String</td>
| status | enumeration | 16 | 0 unsigned | String | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| conflict- | container | 17 | 5 map | Object | <td>target-port-range</td>
| information | | | | | <td>list</td>
+---------------------+--------------+------+-------------+--------+ <td>7</td>
| conflict-status | enumeration | 18 | 0 unsigned | String | <td>4 array</td>
+---------------------+--------------+------+-------------+--------+ <td>Array</td>
| conflict-cause | enumeration | 19 | 0 unsigned | String | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| retry-timer | uint32 | 20 | 0 unsigned | String | <td>lower-port</td>
+---------------------+--------------+------+-------------+--------+ <td>inet:port-number</td>
| conflict-scope | container | 21 | 5 map | Object | <td>8</td>
+---------------------+--------------+------+-------------+--------+ <td>0 unsigned</td>
| acl-list | list | 22 | 4 array | Array | <td>Number</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| acl-name | leafref | 23 | 3 text | String | <tr>
| | | | string | | <td>upper-port</td>
+---------------------+--------------+------+-------------+--------+ <td>inet:port-number</td>
| acl-type | leafref | 24 | 3 text | String | <td>9</td>
| | | | string | | <td>0 unsigned</td>
+---------------------+--------------+------+-------------+--------+ <td>Number</td>
| bytes-dropped | yang:zero- | 25 | 0 unsigned | String | </tr>
| | based- | | | | <tr>
| | counter64 | | | | <td rowspan="2">target-protocol</td>
+---------------------+--------------+------+-------------+--------+ <td>leaf-list</td>
| bps-dropped | yang:gauge64 | 26 | 0 unsigned | String | <td>10</td>
+---------------------+--------------+------+-------------+--------+ <td>4 array</td>
| pkts-dropped | yang:zero- | 27 | 0 unsigned | String | <td>Array</td>
| | based- | | | | </tr>
| | counter64 | | | | <tr>
+---------------------+--------------+------+-------------+--------+ <td>uint8</td>
| pps-dropped | yang:gauge64 | 28 | 0 unsigned | String | <td></td>
+---------------------+--------------+------+-------------+--------+ <td>0 unsigned</td>
| attack-status | enumeration | 29 | 0 unsigned | String | <td>Number</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| ietf-dots-signal- | container | 30 | 5 map | Object | <tr>
| channel:signal- | | | | | <td rowspan="2">target-fqdn</td>
| config | | | | | <td>leaf-list</td>
+---------------------+--------------+------+-------------+--------+ <td>11</td>
| sid | uint32 | 31 | 0 unsigned | Number | <td>4 array</td>
+---------------------+--------------+------+-------------+--------+ <td>Array</td>
| mitigating-config | container | 32 | 5 map | Object | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| heartbeat-interval | container | 33 | 5 map | Object | <td>inet:domain-name</td>
+---------------------+--------------+------+-------------+--------+ <td></td>
| max-value | uint16 | 34 | 0 unsigned | Number | <td>3 text string</td>
+---------------------+--------------+------+-------------+--------+ <td>String</td>
| min-value | uint16 | 35 | 0 unsigned | Number | </tr>
+---------------------+--------------+------+-------------+--------+ <tr>
| current-value | uint16 | 36 | 0 unsigned | Number | <td rowspan="2">target-uri</td>
+---------------------+--------------+------+-------------+--------+ <td>leaf-list</td>
| missing-hb-allowed | container | 37 | 5 map | Object | <td>12</td>
+---------------------+--------------+------+-------------+--------+ <td>4 array</td>
| max-retransmit | container | 38 | 5 map | Object | <td>Array</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| ack-timeout | container | 39 | 5 map | Object | <tr>
+---------------------+--------------+------+-------------+--------+ <td>inet:uri</td>
| ack-random-factor | container | 40 | 5 map | Object | <td></td>
+---------------------+--------------+------+-------------+--------+ <td>3 text string</td>
| max-value-decimal | decimal64 | 41 | 6 tag 4 | String | <td>String</td>
| | | | [-2, | | </tr>
| | | | integer] | | <tr>
+---------------------+--------------+------+-------------+--------+ <td rowspan="2">alias-name</td>
| min-value-decimal | decimal64 | 42 | 6 tag 4 | String | <td>leaf-list</td>
| | | | [-2, | | <td>13</td>
| | | | integer] | | <td>4 array</td>
+---------------------+--------------+------+-------------+--------+ <td>Array</td>
| current-value- | decimal64 | 43 | 6 tag 4 | String | </tr>
| decimal | | | [-2, | | <tr>
| | | | integer] | | <td>string</td>
+---------------------+--------------+------+-------------+--------+ <td></td>
| idle-config | container | 44 | 5 map | Object | <td>3 text string</td>
+---------------------+--------------+------+-------------+--------+ <td>String</td>
| trigger-mitigation | boolean | 45 | 7 bits 20 | False | </tr>
| | | +-------------+--------+ <tr>
| | | | 7 bits 21 | True | <td rowspan="2">lifetime</td>
+---------------------+--------------+------+-------------+--------+ <td rowspan="2">union</td>
| ietf-dots-signal- | container | 46 | 5 map | Object | <td rowspan="2">14</td>
| channel:redirected- | | | | | <td>0 unsigned</td>
| signal | | | | | <td>Number</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| alt-server | inet:domain- | 47 | 3 text | String | <tr>
| | name | | string | | <td>1 negative</td>
+---------------------+--------------+------+-------------+--------+ <td>Number</td>
| alt-server-record | leaf-list | 48 | 4 array | Array | </tr>
| +--------------+------+-------------+--------+ <tr>
| | inet:ip- | | 3 text | String | <td>mitigation-start</td>
| | address | | string | | <td>uint64</td>
+---------------------+--------------+------+-------------+--------+ <td>15</td>
| ietf-dots-signal- | container | 49 | 5 map | Object | <td>0 unsigned</td>
| channel:heartbeat | | | | | <td>String</td>
+---------------------+--------------+------+-------------+--------+ </tr>
| probing-rate | container | 50 | 5 map | Object | <tr>
+---------------------+--------------+------+-------------+--------+ <td>status</td>
| peer-hb-status | boolean | 51 | 7 bits 20 | False | <td>enumeration</td>
| | | +-------------+--------+ <td>16</td>
| | | | 7 bits 21 | True | <td>0 unsigned</td>
+---------------------+--------------+------+-------------+--------+ <td>String</td>
</tr>
Table 5: CBOR Key Values Used in DOTS Signal Channel Messages & <tr>
Their Mappings to JSON and YANG]]></artwork> <td>conflict-information</td>
</figure></t> <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>yang:zero-based-counter64</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>yang:zero-based-counter64</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>ietf-dots-signal-channel:signal-config</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>ietf-dots-signal-channel:redirected-signal</td>
<td>container</td>
<td>46</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>alt-server</td>
<td>inet:domain-name</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>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>ietf-dots-signal-channel:heartbeat</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 respect
to (D)TLS version. Because DOTS signal channel encryption relying upon to (D)TLS version. Because DOTS signal channel encryption relying upon
(D)TLS is virtually a greenfield deployment, DOTS agents MUST (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 it 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
path per <xref target="RFC5280"></xref>. Additionally, the DOTS client certification
MUST use <xref target="RFC6125"></xref> validation techniques to path per <xref target="RFC5280" format="default"/>. Additionally, the
DOTS client
<bcp14>MUST</bcp14> use <xref target="RFC6125" format="default"/>
validation 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>
DNS-ID and SRV-ID identifier types. DOTS servers SHOULD prefer the use support the
of DNS-ID and SRV-ID over CN-ID identifier types in certificate DNS-ID and SRV-ID identifier types. DOTS servers <bcp14>SHOULD</bcp14>
requests (as described in Section 2.3 of <xref prefer the use
target="RFC6125"></xref>), and the wildcard character '*' SHOULD NOT of DNS-ID and SRV-ID over Common Name ID (CN-ID) identifier types in
certificate
requests (as described in <xref target="RFC6125" sectionFormat="of"
section="2.3"/>),
and the wildcard character '*' <bcp14>SHOULD NOT</bcp14>
be included in the presented identifier. DOTS doesn't use URI-IDs for be 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="default"/>
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 to certificate, to authenticate themselves. One deployment option is to
have DOTS clients behave as EST clients for certificate enrollment have DOTS clients behave as EST clients for certificate enrollment
from an EST server provisioned by the mitigation provider. This from an EST server provisioned by the mitigation provider. This
document does not specify which EST or other mechanism the DOTS client document does not specify which EST or other mechanism the DOTS client
uses to achieve initial enrollment.</t> uses to achieve initial enrollment.</t>
<t>The Server Name Indication (SNI) extension <xref target="RFC6066" for
<t>The Server Name Indication (SNI) extension <xref mat="default"/> defines a mechanism for a client to tell a
target="RFC6066"></xref> 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 (<xref target="RFC6347" sectionFormat
<t>DTLS record replay detection (Section 3.3 of <xref ="of"
target="RFC6347"></xref>) or an equivalent mechanism to protect section="3.3"/>) 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="default"/>
<t>At least one of raw public keys <xref target="RFC7250"></xref> or PSK handshake <xref target="RFC4279" format="default"/> with
or PSK handshake <xref target="RFC4279"></xref> with (EC)DHE key (EC)DHE key
exchange. This reduces the size of the ServerHello. Also, this can exchange. This reduces the size of the ServerHello. Also, this can
be used by DOTS agents that cannot obtain certificates.</t> be used by DOTS agents that cannot obtain certificates.</li>
</list></t> </ul>
<t>Implementations compliant with this profile <bcp14>SHOULD</bcp14>
<t>Implementations compliant with this profile SHOULD implement all of implement all of
the following items to reduce the delay required to deliver a DOTS the following items to reduce the delay required to deliver a DOTS
signal channel message:</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 useful latency improvements for connection <t>TLS 1.3 provides useful 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 <xref target="I-D.ietf
target="I-D.ietf-tls-dtls13"></xref> is based upon the TLS 1.3 -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>A full handshake mode in which a DOTS client can send a DOTS
<t>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>
<li>0-RTT mode in which the DOTS client can authenticate itself and
<t>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.</t> likely with the DOTS signal channel.</li>
</list></t> </ul>
<t>The DOTS client has to establish a (D)TLS session with the DOTS <t>The DOTS client has to establish a (D)TLS session with the DOTS
server during 'idle' time and share a PSK.</t> server during 'idle' time and share a PSK.</t>
<t>During a DDoS attack, the DOTS client can use the (D)TLS session to <t>During a DDoS attack, the DOTS client can use the (D)TLS session to
convey the DOTS mitigation request message and, if there is no convey the DOTS mitigation request message and, if there is no
response from the server after multiple retries, the DOTS client can response from the server after multiple retries, the DOTS client can
resume the (D)TLS session in 0-RTT mode using PSK.</t> resume the (D)TLS session in 0-RTT mode using PSK.</t>
<t>DOTS servers that support (D)TLS 1.3 <bcp14>MAY</bcp14> allow DOTS cl
<t>DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to send ients to send
early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping" as early early data (0-RTT). DOTS clients <bcp14>MUST NOT</bcp14> send "CoAP Ping
data; such messages MUST be rejected by DOTS servers. Section 8 of " as early
<xref target="RFC8446"></xref> discusses some mechanisms to implement data; such messages <bcp14>MUST</bcp14> be rejected by DOTS servers.
<xref target="RFC8446" sectionFormat="of" section="8"/> discusses some m
echanisms to
implement
in order to limit the impact of replay attacks on 0-RTT data. If the in order to limit the impact of replay attacks on 0-RTT data. If the
DOTS server accepts 0-RTT, it MUST implement one of these mechanisms DOTS 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 to prevent replay at the TLS layer. A DOTS server can reject 0-RTT by
sending a TLS HelloRetryRequest.</t> sending a TLS HelloRetryRequest.</t>
<t>The DOTS signal channel messages sent as early data by the DOTS <t>The DOTS signal channel messages sent as early data by the DOTS
client are idempotent requests. As a reminder, the Message ID (Section client are idempotent requests. As a reminder, the Message ID
3 of <xref target="RFC7252"></xref>) is changed each time a new CoAP (<xref target="RFC7252" sectionFormat="of" section="3"/>) is changed eac
request is sent, and the Token (Section 5.3.1 of <xref h time a new CoAP
target="RFC7252"></xref>) is randomized in each CoAP request. The DOTS request is sent, and the Token (<xref target="RFC7252" sectionFormat="of
server(s) MUST use the Message ID and the Token in the DOTS signal "
section="5.3.1"/>) is randomized in each CoAP request. The DOTS
server(s) <bcp14>MUST</bcp14> use the Message ID and the Token in the DO
TS signal
channel message to detect replay of early data at the application 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. layer and accept 0-RTT data at most once from the same DOTS client.
This anti-replay defense requires sharing the Message ID and the Token This anti-replay defense requires sharing the Message ID and the Token
in the 0-RTT data between DOTS servers in the DOTS server domain. DOTS in the 0-RTT data between DOTS servers in the DOTS server domain. DOTS
servers do not rely on transport coordinates to identify DOTS peers. servers do not rely on transport coordinates to identify DOTS peers.
As specified in <xref target="post"></xref>, DOTS servers couple the As specified in <xref target="post" format="default"/>, DOTS servers cou ple the
DOTS signal channel sessions using the DOTS client identity and DOTS signal channel sessions using the DOTS client identity and
optionally the 'cdid' parameter value. Furthermore, the 'mid' value is optionally the 'cdid' parameter value. Furthermore, the 'mid' value is
monotonically increased by the DOTS client for each mitigation monotonically increased by the DOTS client for each mitigation
request, thus attackers that replay mitigation requests with lower request, thus attackers that replay mitigation requests with lower
numeric 'mid' values and overlapping scopes with mitigation requests numeric 'mid' values and overlapping scopes with mitigation requests
having higher numeric 'mid' values will be rejected systematically by having higher numeric 'mid' values will be rejected systematically by
the DOTS server. Likewise, the 'sid' value is monotonically increased the DOTS server. Likewise, the 'sid' value is monotonically increased
by the DOTS client for each configuration request (<xref by the DOTS client for each configuration request (<xref target="convey"
target="convey"></xref>); attackers replaying configuration requests format="default"/>); attackers replaying configuration requests
with lower numeric 'sid' values will be rejected by the DOTS server if with lower numeric 'sid' values will be rejected by the DOTS server if
it maintains a higher numeric 'sid' value for this DOTS client.</t> it maintains a higher numeric 'sid' value for this DOTS client.</t>
<t>Owing to the aforementioned protections, all DOTS signal channel <t>Owing to the aforementioned protections, all DOTS signal channel
requests are safe to transmit in TLS 1.3 as early data. Refer to <xref requests are safe to transmit in TLS 1.3 as early data. Refer to <xref t
target="I-D.boucadair-dots-earlydata"></xref> for more details.</t> arget="I-D.boucadair-dots-earlydata" format="default"/> for more details.</t>
<t>A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request <t>A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
message exchange is shown in <xref target="Figure24"></xref>.<figure message exchange is shown in <xref target="Figure24" format="default"/>.
anchor="Figure24" </t>
title="A Simplified TLS 1.3 Handshake with 0-RTT"> <figure anchor="Figure24">
<artwork align="left"><![CDATA[ DOTS Client <name>A Simplified TLS 1.3 Handshake with 0-RTT</name>
DOTS Server <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>
</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, the DLTS records need to decreased probability of message delivery, the DLTS records need to
fit within a single datagram <xref target="RFC6347"></xref>. DTLS fit within a single datagram <xref target="RFC6347" format="default"/>. 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" sectionFormat="of"
target="RFC6347"></xref>). If the path MTU (PMTU) cannot be section="4.1.1"/>). If the Path MTU (PMTU) cannot be
discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 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 requires that every link in the Internet have an MTU of 1280 octets or
greater as specified in <xref target="RFC8200"></xref>. If IPv4 greater, as specified in <xref target="RFC8200" format="default"/>. If I Pv4
support on legacy or otherwise unusual networks is a consideration and support on legacy or otherwise unusual networks is a consideration and
the PMTU is unknown, DOTS implementations MAY assume a PMTU of 576 the PMTU is unknown, DOTS implementations <bcp14>MAY</bcp14> assume a PM
bytes for IPv4 datagrams (see Section 3.3.3 of <xref TU of 576
target="RFC1122"></xref>).</t> bytes for IPv4 datagrams (see <xref target="RFC1122" sectionFormat="of"
section="3.3.3"/>).</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 the CoAP expected by the DTLS processing when calculating the size of the CoAP
message that fits within the PMTU. PMTU MUST be greater than or equal message that fits within the PMTU. The PMTU <bcp14>MUST</bcp14> be great er than or equal
to [CoAP message size + DTLS 1.2 overhead of 13 octets + 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" sectionFormat="of" section="4.1.1.1"/>)
total request size exceeds the PMTU, then the DOTS client MUST split . 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 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><figure> <t>Implementation Note: DOTS choice of message size parameters
<artwork><![CDATA[ | Implementation Note: DOTS choice of messa works well with IPv6 and with most of today's IPv4 paths.
ge size parameters However, with IPv4, it is harder to safely make sure that there
| works well with IPv6 and with most of today's IPv4 paths. is no IP fragmentation. If the IPv4 PMTU is unknown,
| However, with IPv4, it is harder to safely make sure that there implementations may want to limit themselves to more
| is no IP fragmentation. If the IPv4 PMTU is unknown, conservative IPv4 datagram sizes, such as 576 bytes, per
| implementations may want to limit themselves to more <xref target="RFC0791" format="default"/>.</t></aside>
| conservative IPv4 datagram sizes such as 576 bytes, per
| [RFC0791].]]></artwork>
</figure></t>
</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 certificates 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 per <xref client. DOTS client certificate validation must be performed per <xref tar
target="RFC5280"></xref>, and the DOTS client certificate must conform get="RFC5280" format="default"/>, and the DOTS client certificate must conform
to the <xref target="RFC5280"></xref> certificate profile. If a DOTS to the <xref target="RFC5280" format="default"/> certificate profile. If a
DOTS
client does not support TLS client certificate authentication, it must client does not support TLS client certificate authentication, it must
support client authentication based on pre-shared key or raw public support client authentication based on pre-shared key or raw public
key.</t> key.</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
| +-----+----+--+ | +---------------+ | +-----+----+--+ | +---------------+
| +--------------+ | | | | | | +--------------+ | | | | |
skipping to change at line 4292 skipping to change at line 4455
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDoS detector | | | | | DDoS detector | | |
| | (DOTS client) +<-------------+ | | | (DOTS client) +<-------------+ |
| +----------------+ | | +----------------+ |
+---------------------------------------------+ +---------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>In the example depicted in <xref target="Figure12" format="default"/>,
<t>In the example depicted in <xref target="Figure12"></xref>, the DOTS the DOTS
gateway and DOTS clients within the 'example.com' domain proceed with gateway and DOTS clients within the 'example.com' domain proceed with
mutual authentication. After the DOTS gateway validates the identity of mutual authentication. After the DOTS gateway validates the identity of
a DOTS client, it communicates with the AAA server in the 'example.com' a DOTS client, it communicates with the Authentication, Authorization, and
Accounting (AAA) server in the 'example.com'
domain to determine if the DOTS client is authorized to request DDoS domain 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 <xref target
target="Figure12"></xref>, the DOTS server only allows the DOTS gateway ="Figure12" format="default"/>, the DOTS server only allows the DOTS gateway
to request mitigation for the 'example.com' domain and not for other to request mitigation for the 'example.com' domain and not for other
domains.</t> domains.</t>
</section> </section>
<section anchor="errors" numbered="true" toc="default">
<section anchor="errors" title="Error Handling"> <name>Error Handling</name>
<t>This section is a summary of the Error Code responses that can be <t>This section is a summary of the Error Code responses that can be
returned by a DOTS server. These error responses must contain a CoAP returned by a DOTS server. These error responses must contain a CoAP
4.xx or 5.xx Response Code.</t> 4.xx or 5.xx Response Code.</t>
<t>In general, there may be an additional plain text diagnostic payload <t>In general, there may be an additional plain text diagnostic payload
(Section 5.5.2 of <xref target="RFC7252"></xref>) to help (<xref target="RFC7252" sectionFormat="of" section="5.5.2"/>) to help
troubleshooting in the body of the response unless detailed troubleshooting in the body of the response unless detailed
otherwise.</t> otherwise.</t>
<t>Errors returned by a DOTS server can be broken into two categories:
<t>Errors returned by a DOTS server can be broken into two categories,
those associated with CoAP itself and those generated during the those associated with CoAP itself and those generated during the
validation of the provided data by the DOTS server.</t> validation of the provided data by the DOTS server.</t>
<t>The following is a list of common CoAP errors that are implemented by D
<t>The following list of common CoAP errors that are implemented by DOTS OTS
servers. This list is not exhaustive; other errors defined by CoAP and servers. This list is not exhaustive; other errors defined by CoAP and
associated RFCs may be applicable. <list style="hanging"> associated RFCs may be applicable. </t>
<t hangText="4.00 (Bad Request)">is returned by the DOTS server when <dl newline="false" spacing="normal">
<dt>4.00 (Bad Request)</dt>
<dd>is returned by the DOTS server when
the DOTS client has sent a request that violates the DOTS protocol the DOTS client has sent a request that violates the DOTS protocol
(<xref target="sig"></xref>).</t> (<xref target="sig" format="default"/>).</dd>
<dt>4.01 (Unauthorized)</dt>
<t hangText="4.01 (Unauthorized) ">is returned by the DOTS server <dd>is returned by the DOTS server
when the DOTS client is not authorized to access the DOTS server when the DOTS client is not authorized to access the DOTS server
(<xref target="sig"></xref>).</t> (<xref target="sig" format="default"/>).</dd>
<dt>4.02 (Bad Option)</dt>
<t hangText="4.02 (Bad Option)">is returned by the DOTS server when <dd>is returned by the DOTS server when
one or more CoAP options are unknown or malformed by the CoAP layer one or more CoAP options are unknown or malformed by the CoAP layer
<xref target="RFC7252"></xref>.</t> <xref target="RFC7252" format="default"/>.</dd>
<dt>4.04 (Not Found)</dt>
<t hangText="4.04 (Not Found)">is returned by the DOTS server when <dd>is returned by the DOTS server when
the DOTS client is requesting a 'mid' or 'sid' that is not valid the DOTS client is requesting a 'mid' or 'sid' that is not valid
(<xref target="sig"></xref>).</t> (<xref target="sig" format="default"/>).</dd>
<dt>4.05 (Method Not Allowed)</dt>
<t hangText="4.05 (Method Not Allowed)">is returned by the DOTS <dd>is returned by the DOTS
server when the DOTS client is requesting a resource by a method server when the DOTS client is requesting a resource by a method
(e.g., GET) that is not supported by the DOTS server <xref (e.g., GET) that is not supported by the DOTS server <xref target="RFC
target="RFC7252"></xref>.</t> 7252" format="default"/>.</dd>
<dt>4.08 (Request Entity Incomplete)</dt>
<t hangText="4.08 (Request Entity Incomplete)">is returned by the <dd>is returned by the
DOTS server if one or multiple blocks of a block transfer request is DOTS server if one or multiple blocks of a block transfer request is
missing <xref target="RFC7959"></xref>.</t> missing <xref target="RFC7959" format="default"/>.</dd>
<dt>4.09 (Conflict)</dt>
<t hangText="4.09 (Conflict)">is returned by the DOTS server if the <dd>is returned by the DOTS server if the
DOTS server detects that a request conflicts with a previous DOTS server detects that a request conflicts with a previous
request. The response body is formatted using request. The response body is formatted using
"application/dots+cbor", and contains the "conflict-clause" (<xref "application/dots+cbor" and contains the "conflict-clause" (<xref targ
target="m_req"></xref>).</t> et="pro-mit-req"
format="default"/>).</dd>
<t hangText="4.13 (Request Entity Too Large)">may be returned by the <dt>4.13 (Request Entity Too Large)</dt>
DOTS server during a block transfer request <xref <dd>may be returned by the
target="RFC7959"></xref>.</t> DOTS server during a block transfer request <xref target="RFC7959" for
mat="default"/>.</dd>
<t hangText="4.15 (Unsupported Content-Format)">is returned by the <dt>4.15 (Unsupported Content-Format)</dt>
<dd>is returned by the
DOTS server when the Content-Format is used but the request is not DOTS server when the Content-Format is used but the request is not
formatted as "application/dots+cbor" (<xref formatted as "application/dots+cbor" (<xref target="sig" format="defau
target="sig"></xref>).</t> lt"/>).</dd>
<dt>4.22 (Unprocessable Entity)</dt>
<t hangText="4.22 (Unprocessable Entity)">is returned by the DOTS <dd>is returned by the DOTS
server when one or more session configuration parameters are not server when one or more session configuration parameters are not
valid (<xref target="sigconfig"></xref>).</t> valid (<xref target="sigconfig" format="default"/>).</dd>
<dt>5.03 (Service Unavailable)</dt>
<t hangText="5.03 (Service Unavailable)">is returned by the DOTS <dd>is returned by the DOTS
server if the DOTS server is unable to handle the request (<xref server if the DOTS server is unable to handle the request (<xref targe
target="sig"></xref>). An example is the DOTS server needs to t="sig" format="default"/>). An example is the DOTS server needs to
redirect the DOTS client to use an alternate DOTS server (<xref redirect the DOTS client to use an alternate DOTS server (<xref target
target="redirect"></xref>). The response body is formatted using ="redirect" format="default"/>). The response body is formatted using
"application/dots+cbor", and contains how to handle the 5.03 "application/dots+cbor" and contains how to handle the 5.03
Response Code.</t> Response Code.</dd>
<dt>5.08 (Hop Limit Reached)</dt>
<t hangText="5.08 (Hop Limit Reached)">is returned by the DOTS <dd>is returned by the DOTS
server if there is a data path loop through upstream DOTS gateways. server if there is a data path loop through upstream DOTS gateways.
The response body is formatted using plain text and contains a list The response body is formatted using plain text and contains a list
of servers that are in the data path loop <xref of servers that are in the data path loop <xref target="RFC8768" forma
target="RFC8768"></xref>.</t> t="default"/>.</dd>
</list></t> </dl>
<t></t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t></t> <section anchor="port" numbered="true" toc="default">
<name>DOTS Signal Channel UDP and TCP Port Number</name>
<section anchor="port"
title="DOTS Signal Channel UDP and TCP Port Number">
<t>IANA has assigned the port number 4646 (the ASCII decimal value for <t>IANA has assigned the port number 4646 (the ASCII decimal value for
".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP
from the "Service Name and Transport Protocol Port Number Registry" from the "Service Name and Transport Protocol Port Number Registry"
available at &lt;https://www.iana.org/assignments/service-names-port- available at <eref brackets="angle"
numbers/&gt;.</t> target="https://www.iana.org/assignments/service-names-port-numbers/"/>.<
/t>
<t>IANA is requested to update these entries with the RFC number to be <t>IANA has updated these entries to refer to this document and updated
assigned to this document:</t> the Description as described below:</t>
<dl newline="false" spacing="compact">
<t><figure> <dt>Service Name:</dt>
<artwork><![CDATA[ Service Name: dots-signal <dd>dots-signal</dd>
Port Number: 4646 <dt>Port Number:</dt>
Transport Protocol: TCP <dd>4646</dd>
Description: Distributed Denial-of-Service Open Threat Signaling <dt>Transport Protocol:</dt>
(DOTS) Signal Channel <dd>TCP</dd>
Assignee: IESG <dt>Description:</dt>
Contact: IETF Chair <dd>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Chan
Registration Date: 2020-01-16 nel Protocol. The service name is used to construct the SRV service names "_dots
Reference: [RFCXXXX] -signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to estab
lish DOTS signal channel.</dd>
Service Name: dots-signal <dt>Assignee:</dt>
Port Number: 4646 <dd>IESG</dd>
Transport Protocol: UDP <dt>Contact:</dt>
Description: Distributed Denial-of-Service Open Threat Signaling <dd>IETF Chair</dd>
(DOTS) Signal Channel <dt>Registration Date:</dt>
Assignee: IESG <dd>2020-01-16</dd>
Contact: IETF Chair <dt>Reference:</dt>
Registration Date: 2020-01-16 <dd>[RFC8973][RFC9132]</dd>
Reference: [RFCXXXX]]]></artwork> </dl>
</figure></t> <dl newline="false" spacing="compact">
<dt>Service Name:</dt>
<t></t> <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 Chan
nel Protocol. The service name is used to construct the SRV service names "_dots
-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to estab
lish 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>[RFC8973][RFC9132]</dd>
</dl>
</section> </section>
<section anchor="uri" numbered="true" toc="default">
<section anchor="uri" title="Well-Known 'dots' URI"> <name>Well-Known 'dots' URI</name>
<t>IANA is requested to update the 'dots' well-known URI (Table 6) <t>IANA has updated the 'dots' well-known URI (<xref target="table6"
entry in the Well- Known URIs registry <xref target="URI"></xref> as format="default"/>)
entry in the "Well-Known URIs" registry <xref target="URI" format="defau
lt"/> as
follows:</t> follows:</t>
<table anchor="table6" align="center">
<t><figure align="center"> <name>'dots' Well-Known URI</name>
<artwork align="center"><![CDATA[ +------------+------------+--- <thead>
--------+-----------+-------------+ <tr>
| URI Suffix | Change | Reference | Status | Related | <th>URI Suffix</th>
| | Controller | | | information | <th>Change Controller</th>
+============+============+===========+===========+=============+ <th>Reference</th>
| dots | IETF | [RFCXXXX] | permanent | None | <th>Status</th>
+------------+------------+-----------+-----------+-------------+ <th>Related information</th>
</tr>
Table 6: 'dots' Well-Known URI]]></artwork> </thead>
</figure></t> <tbody>
<tr>
<td>dots</td>
<td>IETF</td>
<td>[RFC9132]</td>
<td>permanent</td>
<td>None</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="MediaReg" numbered="true" toc="default">
<section anchor="MediaReg" title="Media Type Registration"> <name>Media Type Registration</name>
<t>IANA is requested to update the "application/dots+cbor" media type <t>IANA has updated the "application/dots+cbor" media type
in the "Media Types" registry <xref target="IANA-MediaTypes"></xref> in the "Media Types" registry <xref target="IANA-MediaTypes" format="def
in the manner described in <xref target="RFC6838"></xref>, which can ault"/>
in the manner described in <xref target="RFC6838" format="default"/>, wh
ich can
be used to indicate that the content is a DOTS signal channel be used to indicate that the content is a DOTS signal channel
object:<figure> object:</t>
<artwork><![CDATA[ Type name: application <dl newline="false" spacing="normal">
<dt>Type name:</dt>
Subtype name: dots+cbor <dd>application</dd>
<dt>Subtype name:</dt>
Required parameters: N/A <dd>dots+cbor</dd>
<dt>Required parameters:</dt>
Optional parameters: N/A <dd>N/A</dd>
<dt>Optional parameters:</dt>
Encoding considerations: binary <dd>N/A</dd>
<dt>Encoding considerations:</dt>
Security considerations: See the Security Considerations section of <dd>binary</dd>
[RFCXXXX]. <dt>Security considerations:</dt>
<dd>See the Security Considerations section of
Interoperability considerations: N/A RFC 9132.</dd>
<dt>Interoperability considerations:</dt>
Published specification: [RFCXXXX] <dd>N/A</dd>
<dt>Published specification:</dt>
Applications that use this media type: DOTS agents sending DOTS <dd>RFC 9132</dd>
messages over CoAP over (D)TLS. <dt>Applications that use this media type:</dt>
<dd>DOTS agents sending DOTS
Fragment identifier considerations: N/A messages over CoAP over (D)TLS.</dd>
<dt>Fragment identifier considerations:</dt>
Additional information: <dd>N/A</dd>
</dl>
Deprecated alias names for this type: N/A <dl newline="true" spacing="normal">
Magic number(s): N/A <dt>Additional information:</dt>
File extension(s): N/A <dd>
Macintosh file type code(s): N/A
Person & email address to contact for further information: IESG,
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors' Addresses section.
Change controller: IESG
Provisional registration? No]]></artwork> <dl newline="false" spacing="compact">
</figure></t> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd>
<dt>Magic number(s):</dt>
<dd>N/A</dd>
<dt>File extension(s):</dt>
<dd>N/A</dd>
<dt>Macintosh file type code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
</dl>
<dl newline="false" spacing="normal">
<dt>Person &amp; email address to contact for further information:</dt>
<dd><br/>IESG, iesg@ietf.org</dd>
<dt>Intended usage:</dt>
<dd>COMMON</dd>
<dt>Restrictions on usage:</dt>
<dd>none</dd>
<dt>Author:</dt>
<dd>See Authors' Addresses section.</dd>
<dt>Change controller:</dt>
<dd>IESG</dd>
<dt>Provisional registration?</dt>
<dd>No</dd>
</dl>
</section> </section>
<section anchor="IANACoAPContentFormatRegistration" <section anchor="IANACoAPContentFormatRegistration" numbered="true" toc="d
title="CoAP Content-Formats Registration"> efault">
<t>IANA is requested to update the CoAP Content-Format ID for the <name>CoAP Content-Formats Registration</name>
"application/ dots+cbor" media type in the "CoAP Content-Formats" <t>IANA has updated the
registry <xref target="IANA-CoAP-Content-Formats"></xref>:<?rfc subcompa "application/dots+cbor" media type in the "CoAP Content-Formats"
ct="yes"?></t> registry <xref target="IANA-CoAP-Content-Formats" format="default"/> as
follows:</t>
<t><list style="symbols"> <dl newline="false" spacing="compact">
<t>Media Type: application/dots+cbor</t> <dt>Media Type:</dt>
<dd>application/dots+cbor</dd>
<t>Encoding: -</t> <dt>Encoding:</dt>
<dd>-</dd>
<t>Id: 271</t> <dt>ID:</dt>
<dd>271</dd>
<t>Reference: [RFCXXXX]</t> <dt>Reference:</dt>
</list></t> <dd>[RFC9132]</dd>
</dl>
<?rfc subcompact="no"?>
</section> </section>
<section anchor="IANACBORTagAssignment" numbered="true" toc="default">
<section anchor="IANACBORTagAssignment" title="CBOR Tag Registration"> <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. The DOTS CBOR in which this information would not otherwise be known. The DOTS CBOR
tag is not required for DOTS signal channel protocol version specified tag is not required for the DOTS signal channel protocol version specifi
in this document. If present, the DOTS tag MUST prefix a DOTS signal ed
in this document. If present, the DOTS tag <bcp14>MUST</bcp14> prefix a
DOTS signal
channel object.</t> channel object.</t>
<t>IANA has updated the DOTS signal channel CBOR tag in the
<t>IANA is requested to update the DOTS signal channel CBOR tag in the "CBOR Tags" registry <xref target="IANA-CBOR-Tags" format="default"/> as
"CBOR Tags" registry <xref target="IANA-CBOR-Tags"></xref>:<?rfc subcomp follows:</t>
act="yes"?></t> <dl newline="false" spacing="compact">
<dt>Tag:</dt>
<t><figure> <dd>271</dd>
<artwork><![CDATA[ * Tag: 271 <dt>Data Item:</dt>
* Data Item: DDoS Open Threat Signaling (DOTS) signal channel object <dd>DDoS Open Threat Signaling (DOTS) signal channel object</dd>
* Semantics: DDoS Open Threat Signaling (DOTS) signal channel <dt>Semantics:</dt>
object, as defined in [RFCXXXX] <dd>DDoS Open Threat Signaling (DOTS) signal channel
* Reference: [RFCXXXX]]]></artwork> object, as defined in [RFC9132]</dd>
</figure></t> <dt>Reference:</dt>
<dd>[RFC9132]</dd>
<?rfc subcompact="no"?> </dl>
</section> </section>
<section anchor="reg" title="DOTS Signal Channel Protocol Registry"> <section anchor="reg" numbered="true" toc="default">
<t>The following sections update the "Distributed Denial-of- Service <name>DOTS Signal Channel Protocol Registry</name>
Open Threat Signaling (DOTS) Signal Channel" subregistries <xref <t>The following sections update the "Distributed Denial-of-Service
target="REG-DOTS"></xref>.</t> Open Threat Signaling (DOTS) Signal Channel" subregistries <xref target=
"REG-DOTS" format="default"/>.</t>
<section anchor="map" <section anchor="map" numbered="true" toc="default">
title="DOTS Signal Channel CBOR Key Values Subregistry"> <name>DOTS Signal Channel CBOR Key Values Subregistry</name>
<t>The structure of this subregistry is provided in <xref <t>The structure of this subregistry is provided in <xref target="form
target="format"></xref>.</t> at" format="default"/>.</t>
<section anchor="format" numbered="true" toc="default">
<section anchor="format" title="Registration Template"> <name>Registration Template</name>
<t>This specification requests IANA to update the allocation <t>IANA has updated the allocation
policy of "DOTS Signal Channel CBOR Key Values" registry as policy of "DOTS Signal Channel CBOR Key Values" registry as
follows:<list style="hanging"> follows:</t>
<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>
range. <vspace blankLines="1" /><figure> <dd>
<artwork align="center"><![CDATA[OLD: <t>Key value for the
+-------------+-------------------------+------------------------+ parameter. The key value <bcp14>MUST</bcp14> be an integer in th
| Range | Registration Procedures | Note | e 1-65535
+=============+=========================+========================+ range. </t>
| 1-16383 | IETF Review | comprehension-required | <t>OLD:</t>
| 16384-32767 | Specification Required | comprehension-optional | <table anchor="old" align="center">
| 32768-49151 | IETF Review | comprehension-optional | <thead>
| 49152-65535 | Private Use | comprehension-optional | <tr>
+-------------+-------------------------+------------------------+ <th>Range</th>
<th>Registration Procedures</th>
NEW: <th>Note</th>
+-------------+-------------------------+------------------------+ </tr>
| Range | Registration Procedures | Note | </thead>
+=============+=========================+========================+ <tbody>
| 1-127 | IETF Review | comprehension-required | <tr>
| 128-255 | IETF Review | comprehension-optional | <td>1-16383</td>
| 256-16383 | IETF Review | comprehension-required | <td>IETF Review</td>
| 16384-32767 | Specification Required | comprehension-optional | <td>comprehension-required</td>
| 32768-49151 | IETF Review | comprehension-optional | </tr>
| 49152-65535 | Private Use | comprehension-optional | <tr>
+-------------+-------------------------+------------------------+]]></artwork> <td>16384-32767</td>
</figure><vspace blankLines="1" />Registration requests for <td>Specification Required</td>
<td>comprehension-optional</td>
</tr>
<tr>
<td>32768-49151</td>
<td>IETF Review</td>
<td>comprehension-optional</td>
</tr>
<tr>
<td>49152-65535</td>
<td>Private Use</td>
<td>comprehension-optional</td>
</tr>
</tbody>
</table>
<t>NEW:</t>
<table anchor="new" align="center">
<thead>
<tr>
<th>Range</th>
<th>Registration Procedures</th>
<th>Note</th>
</tr>
</thead>
<tbody>
<tr>
<td>1-127</td>
<td>IETF Review</td>
<td>comprehension-required</td>
</tr>
<tr>
<td>128-255</td>
<td>IETF Review</td>
<td>comprehension-optional</td>
</tr>
<tr>
<td>256-16383</td>
<td>IETF Review</td>
<td>comprehension-required</td>
</tr>
<tr>
<td>16384-32767</td>
<td>Specification Required</td>
<td>comprehension-optional</td>
</tr>
<tr>
<td>32768-49151</td>
<td>IETF Review</td>
<td>comprehension-optional</td>
</tr>
<tr>
<td>49152-65535</td>
<td>Private Use</td>
<td>comprehension-optional</td>
</tr>
</tbody>
</table>
<t>Registration requests for
the 16384-32767 range are evaluated after a three-week review the 16384-32767 range are evaluated after a three-week review
period on the dots-signal-reg-review@ietf.org mailing list, on period on the dots-signal-reg-review@ietf.org mailing list, on
the advice of one or more Designated Experts. However, to the advice of one or more designated experts. However, to
allow for the allocation of values prior to publication, the allow for the allocation of values prior to publication, the
Designated Experts may approve registration once they are designated experts may approve registration once they are
satisfied that such a specification will be published. New satisfied that such a specification will be published. New
registration requests should be sent in the form of an email registration requests should be sent in the form of an email
to the review mailing list; the request should use an to the review mailing list; the request should use an
appropriate subject (e.g., "Request to register CBOR Key Value appropriate subject (e.g., "Request to register CBOR Key Value
for DOTS: example"). IANA will only accept new registrations for DOTS: example"). IANA will only accept new registrations
from the Designated Experts, and it will check that review was from the designated experts, and it will check that review was
requested on the mailing list in accordance with these requested on the mailing list in accordance with these
procedures.<vspace blankLines="1" />Within the review period, procedures.</t>
the Designated Experts will either approve or deny the <t>Within the review period,
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 include 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 16384-32767 range from the Designated registry updates to the 16384-32767 range from the designated
Experts and should direct all requests for registration to the experts and should direct all requests for registration to the
review mailing list. It is suggested that multiple Designated review mailing list. It is suggested that multiple designated
Experts be appointed. In cases where a registration decision experts be appointed. In cases where a registration decision
could be perceived as creating a conflict of interest for a could be perceived as creating a conflict of interest for a
particular Expert, that Expert should defer to the judgment of particular expert, that expert should defer to the judgment of
the other Experts.</t> 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">
<section anchor="initial" title="Update Subregistry Content"> <name>Update Subregistry Content</name>
<t>IANA is requested to update entries in the "0-51" and <t>IANA has updated entries in the "0-51" and
"49152-65535" ranges from the "DOTS Signal Channel CBOR Key "49152-65535" ranges from the "DOTS Signal Channel CBOR Key
Values" registry with the RFC number to be assigned to this Values" registry to refer this RFC.</t>
document.</t>
</section> </section>
</section> </section>
<section anchor="sc" numbered="true" toc="default">
<section anchor="sc" title="Status Codes Subregistry"> <name>Status Codes Subregistry</name>
<t>IANA is requested to update these entries from the "DOTS Signal <t>IANA has updated the following entries from the "DOTS Signal
Channel Status Codes" registry with the RFC number to be assigned to Channel Status Codes" registry to refer to this RFC:</t>
this document:</t> <table anchor="table7" align="center">
<name>Initial DOTS Signal Channel Status Codes</name>
<t><figure> <thead>
<artwork><![CDATA[ +--------------+---------------+------------ <tr>
----------+-----------+ <th>Code</th>
| Code | Label | Description | Reference | <th>Label</th>
+==============+===============+======================+===========+ <th>Description</th>
| 0 | Reserved | | [RFCXXXX] | <th>Reference</th>
+--------------+---------------+----------------------+-----------+ </tr>
| 1 | attack- | Attack mitigation | [RFCXXXX] | </thead>
| | mitigation- | setup is in progress | | <tbody>
| | in-progress | (e.g., changing the | | <tr>
| | | network path to | | <td>0</td>
| | | redirect the inbound | | <td>Reserved</td>
| | | traffic to a DOTS | | <td></td>
| | | mitigator). | | <td>[RFC9132]</td>
+--------------+---------------+----------------------+-----------+ </tr>
| 2 | attack- | Attack is being | [RFCXXXX] | <tr>
| | successfully- | successfully | | <td>1</td>
| | mitigated | mitigated (e.g., | | <td>attack-mitigation-in-progress</td>
| | | traffic is | | <td>Attack mitigation setup is in progress (e.g., changing the network pat
| | | redirected to a DDoS | | h to redirect the inbound traffic to a DOTS mitigator).</td>
| | | mitigator and attack | | <td>[RFC9132]</td>
| | | traffic is dropped). | | </tr>
+--------------+---------------+----------------------+-----------+ <tr>
| 3 | attack- | Attack has stopped | [RFCXXXX] | <td>2</td>
| | stopped | and the DOTS client | | <td>attack-successfully-mitigated</td>
| | | can withdraw the | | <td>Attack is being successfully mitigated (e.g., traffic is redirected to
| | | mitigation request. | | a DDoS mitigator and attack traffic is dropped).</td>
+--------------+---------------+----------------------+-----------+ <td>[RFC9132]</td>
| 4 | attack- | Attack has exceeded | [RFCXXXX] | </tr>
| | exceeded- | the mitigation | | <tr>
| | capability | provider capability. | | <td>3</td>
+--------------+---------------+----------------------+-----------+ <td>attack-stopped</td>
| 5 | dots-client- | DOTS client has | [RFCXXXX] | <td>Attack has stopped and the DOTS client can withdraw the mitigation req
| | withdrawn- | withdrawn the | | uest.</td>
| | mitigation | mitigation request | | <td>[RFC9132]</td>
| | | and the mitigation | | </tr>
| | | is active but | | <tr>
| | | terminating. | | <td>4</td>
+--------------+---------------+----------------------+-----------+ <td>attack-exceeded-capability</td>
| 6 | attack- | Attack mitigation is | [RFCXXXX] | <td>Attack has exceeded the mitigation provider capability.</td>
| | mitigation- | now terminated. | | <td>[RFC9132]</td>
| | terminated | | | </tr>
+--------------+---------------+----------------------+-----------+ <tr>
| 7 | attack- | Attack mitigation is | [RFCXXXX] | <td>5</td>
| | mitigation- | withdrawn. | | <td>dots-client-withdrawn-mitigation</td>
| | withdrawn | | | <td>DOTS client has withdrawn the mitigation request and the mitigation is
+--------------+---------------+----------------------+-----------+ active but terminating.</td>
| 8 | attack- | Attack mitigation | [RFCXXXX] | <td>[RFC9132]</td>
| | mitigation- | will be triggered | | </tr>
| | signal-loss | for the mitigation | | <tr>
| | | request only when | | <td>6</td>
| | | the DOTS signal | | <td>attack-mitigation-terminated</td>
| | | channel session is | | <td>Attack mitigation is now terminated.</td>
| | | lost. | | <td>[RFC9132]</td>
+--------------+---------------+----------------------+-----------+ </tr>
| 9-2147483647 | Unassigned | | | <tr>
+--------------+---------------+----------------------+-----------+ <td>7</td>
<td>attack-mitigation-withdrawn</td>
Table 7: Initial DOTS Signal Channel Status Codes]]></artwork> <td>Attack mitigation is withdrawn.</td>
</figure></t> <td>[RFC9132]</td>
</tr>
<t>New codes can be assigned via Standards Action <xref <tr>
target="RFC8126"></xref>.</t> <td>8</td>
<td>attack-mitigation-signal-loss</td>
<td>Attack mitigation will be triggered for the mitigation request only wh
en the DOTS signal channel session is lost.</td>
<td>[RFC9132]</td>
</tr>
<tr>
<td>9-2147483647</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<t>New codes can be assigned via Standards Action <xref target="RFC812
6" format="default"/>.</t>
</section> </section>
<section anchor="cs" numbered="true" toc="default">
<section anchor="cs" title="Conflict Status Codes Subregistry"> <name>Conflict Status Codes Subregistry</name>
<t>IANA is requested to update these entries from the "DOTS Signal <t>IANA has updated the following entries from the "DOTS Signal
Channel Conflict Status Codes" registry with the RFC number to be Channel Conflict Status Codes" registry to refer to this RFC.</t>
assigned to this document:</t> <table anchor="table8" align="center">
<name>Initial DOTS Signal Channel Conflict Status Codes</name>
<t><figure> <thead>
<artwork><![CDATA[ +--------------+-------------------+--------- <tr>
-----------+-----------+ <th>Code</th>
| Code | Label | Description | Reference | <th>Label</th>
+==============+===================+====================+===========+ <th>Description</th>
| 0 | Reserved | | [RFCXXXX] | <th>Reference</th>
+--------------+-------------------+--------------------+-----------+ </tr>
| 1 | request-inactive- | DOTS server | [RFCXXXX] | </thead>
| | other-active | has detected | | <tbody>
| | | conflicting | | <tr>
| | | mitigation | | <td>0</td>
| | | requests from | | <td>Reserved</td>
| | | different DOTS | | <td></td>
| | | clients. This | | <td>[RFC9132]</td>
| | | mitigation | | </tr>
| | | request is | | <tr>
| | | currently | | <td>1</td>
| | | inactive until | | <td>request-inactive-other-active</td>
| | | the conflicts | | <td>DOTS server has detected conflicting mitigation requests from differen
| | | are resolved. | | t DOTS clients. This mitigation request is currently inactive until the conflict
| | | Another | | s are resolved. Another mitigation request is active.</td>
| | | mitigation | | <td>[RFC9132]</td>
| | | request is | | </tr>
| | | active. | | <tr>
+--------------+-------------------+--------------------+-----------+ <td>2</td>
| 2 | request-active | DOTS server | [RFCXXXX] | <td>request-active</td>
| | | has detected | | <td>DOTS server has detected conflicting mitigation requests from differen
| | | conflicting | | t DOTS clients. This mitigation request is currently active.</td>
| | | mitigation | | <td>[RFC9132]</td>
| | | requests from | | </tr>
| | | different DOTS | | <tr>
| | | clients. This | | <td>3</td>
| | | mitigation | | <td>all-requests-inactive</td>
| | | request is | | <td>DOTS server has detected conflicting mitigation requests from differen
| | | currently | | t DOTS clients. All
| | | active. | | conflicting mitigation requests are inactive.</td>
+--------------+-------------------+--------------------+-----------+ <td>[RFC9132]</td>
| 3 | all-requests- | DOTS server | [RFCXXXX] | </tr>
| | inactive | has detected | | <tr>
| | | conflicting | | <td>4-2147483647</td>
| | | mitigation | | <td>Unassigned</td>
| | | requests from | | <td></td>
| | | different DOTS | | <td></td>
| | | clients. All | | </tr>
| | | conflicting | | </tbody>
| | | mitigation | | </table>
| | | requests are | | <t>New codes can be assigned via Standards Action <xref target="RFC812
| | | inactive. | | 6" format="default"/>.</t>
+--------------+-------------------+--------------------+-----------+
| 4-2147483647 | Unassigned | | |
+--------------+-------------------+--------------------+-----------+
Table 8: Initial DOTS Signal Channel Conflict Status Codes]]></artwork>
</figure></t>
<t>New codes can be assigned via Standards Action <xref
target="RFC8126"></xref>.</t>
</section> </section>
<section anchor="cc" numbered="true" toc="default">
<section anchor="cc" title="Conflict Cause Codes Subregistry"> <name>Conflict Cause Codes Subregistry</name>
<t>IANA is requested to update these entries from the "DOTS Signal <t>IANA has updated the following entries from the "DOTS Signal
Channel Conflict Cause Codes" registry with the RFC number to be Channel Conflict Cause Codes" registry to refer to this document:</t>
assigned to this document:</t> <table anchor="table9" align="center">
<name>Initial DOTS Signal Channel Conflict Cause Codes</name>
<t><figure> <thead>
<artwork><![CDATA[ +--------------+---------------------+------ <tr>
----------+-----------+ <th>Code</th>
| Code | Label | Description | Reference | <th>Label</th>
+==============+=====================+================+===========+ <th>Description</th>
| 0 | Reserved | | [RFCXXXX] | <th>Reference</th>
+--------------+---------------------+----------------+-----------+ </tr>
| 1 | overlapping-targets | Overlapping | [RFCXXXX] | </thead>
| | | targets. | | <tbody>
+--------------+---------------------+----------------+-----------+ <tr>
| 2 | conflict-with- | Conflicts with | [RFCXXXX] | <td>0</td>
| | acceptlist | an existing | | <td>Reserved</td>
| | | accept-list. | | <td></td>
| | | This code is | | <td>[RFC9132]</td>
| | | returned when | | </tr>
| | | the DDoS | | <tr>
| | | mitigation | | <td>1</td>
| | | detects source | | <td>overlapping-targets</td>
| | | addresses/ | | <td>Overlapping targets.</td>
| | | prefixes in | | <td>[RFC9132]</td>
| | | the accept- | | </tr>
| | | listed ACLs | | <tr>
| | | are attacking | | <td>2</td>
| | | the target. | | <td>conflict-with-acceptlist</td>
+--------------+---------------------+----------------+-----------+ <td>Conflicts with an existing accept-list. This code is returned when the
| 3 | cuid-collision | CUID | [RFCXXXX] | DDoS mitigation detects source addresses/prefixes in the accept-listed ACLs are
| | | Collision. | | attacking the target.</td>
| | | This code is | | <td>[RFC9132]</td>
| | | returned when | | </tr>
| | | a DOTS client | | <tr>
| | | uses a 'cuid' | | <td>3</td>
| | | that is | | <td>cuid-collision</td>
| | | already used | | <td>CUID Collision. This code is returned when a DOTS client uses a 'cuid'
| | | by another | | that is already used by another DOTS client.</td>
| | | DOTS client. | | <td>[RFC9132]</td>
+--------------+---------------------+----------------+-----------+ </tr>
| 4-2147483647 | Unassigned | | | <tr>
+--------------+---------------------+----------------+-----------+ <td>4-2147483647</td>
<td>Unassigned</td>
Table 9: Initial DOTS Signal Channel Conflict Cause Codes]]></artwork> <td></td>
</figure></t> <td></td>
</tr>
<t>New codes can be assigned via Standards Action <xref </tbody>
target="RFC8126"></xref>.</t> </table>
<t>New codes can be assigned via Standards Action <xref target="RFC812
6" format="default"/>.</t>
</section> </section>
<section anchor="as" numbered="true" toc="default">
<section anchor="as" title="Attack Status Codes Subregistry"> <name>Attack Status Codes Subregistry</name>
<t>IANA is requested to update these entries from the "DOTS Signal <t>IANA has updated the following entries from the "DOTS Signal
Channel Attack Status Codes" registry with the RFC number to be Channel Attack Status Codes" registry to refer to this RFC:</t>
assigned to this document:</t> <table anchor="table10" align="center">
<name>Initial DOTS Signal Channel Attack Status Codes</name>
<t><figure> <thead>
<artwork><![CDATA[ +--------------+----------------------+------ <tr>
-----------+-----------+ <th>Code</th>
| Code | Label | Description | Reference | <th>Label</th>
+==============+======================+=================+===========+ <th>Description</th>
| 0 | Reserved | | [RFCXXXX] | <th>Reference</th>
+--------------+----------------------+-----------------+-----------+ </tr>
| 1 | under-attack | The DOTS | [RFCXXXX] | </thead>
| | | client | | <tbody>
| | | determines | | <tr>
| | | that it is | | <td>0</td>
| | | still under | | <td>Reserved</td>
| | | attack. | | <td></td>
+--------------+----------------------+-----------------+-----------+ <td>[RFC9132]</td>
| 2 | attack-successfully- | The DOTS | [RFCXXXX] | </tr>
| | mitigated | client | | <tr>
| | | determines | | <td>1</td>
| | | that the | | <td>under-attack</td>
| | | attack is | | <td>The DOTS client determines that it is still under attack.</td>
| | | successfully | | <td>[RFC9132]</td>
| | | mitigated. | | </tr>
+--------------+----------------------+-----------------+-----------+ <tr>
| 3-2147483647 | Unassigned | | | <td>2</td>
+--------------+----------------------+-----------------+-----------+ <td>attack-successfully-mitigated</td>
<td>The DOTS client determines that the attack is successfully mitigated.<
Table 10: Initial DOTS Signal Channel Attack Status Codes]]></artwork> /td>
</figure></t> <td>[RFC9132]</td>
</tr>
<t>New codes can be assigned via Standards Action <xref <tr>
target="RFC8126"></xref>.</t> <td>3-2147483647</td>
<td>Unassigned</td>
<td></td>
<td></td>
</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" numbered="true" toc="default">
<name>DOTS Signal Channel YANG Modules</name>
<t>IANA has registered the following URIs in the "ns" subregistry
within the "IETF XML Registry" <xref target="RFC3688" format="default"/>
: </t>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:iana-dots-signal-channel</dd>
<dt>Registrant Contact:</dt>
<dd>IANA.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>IANA has updated the following YANG
module in the "YANG Module Names" subregistry <xref target="RFC6020" for
mat="default"/> within the "YANG Parameters" registry.</t>
<section anchor="yang" title="DOTS Signal Channel YANG Modules"> <dl newline="false" spacing="compact">
<t>IANA already registered the following URIs in the "ns" subregistry <dt>Name:</dt>
within the "IETF XML Registry" <xref target="RFC3688"></xref>: <figure> <dd>iana-dots-signal-channel</dd>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots- <dt>Maintained by IANA:</dt>
signal-channel <dd>Y</dd>
Registrant Contact: The IESG. <dt>Namespace:</dt>
XML: N/A; the requested URI is an XML namespace. <dd>urn:ietf:params:xml:ns:yang:iana-dots-signal-channel</dd>
<dt>Prefix:</dt>
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel <dd>iana-dots-signal</dd>
Registrant Contact: IANA. <dt>Reference:</dt>
XML: N/A; the requested URI is an XML namespace. <dd>[RFC9132]</dd>
]]></artwork> </dl>
</figure>This document requests IANA to update the following YANG <t>IANA has registered the additional following YANG module in the "YANG Module
modules in the "YANG Module Names" subregistry <xref Names" subregistry <xref target="RFC6020" format="default"/> within the "YANG P
target="RFC6020"></xref> within the "YANG Parameters" registry.<figure> arameters" registry. This obsoletes the registration in <xref target="RFC8782"
<artwork><![CDATA[ Name: ietf-dots-signal-channel format="default"/>.</t>
Maintained by IANA: N <dl newline="false" spacing="compact">
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel <dt>Name:</dt>
Prefix: dots-signal <dd>ietf-dots-signal-channel</dd>
Reference: RFCXXXX <dt>Maintained by IANA:</dt>
<dd>N</dd>
Name: iana-dots-signal-channel <dt>Namespace:</dt>
Maintained by IANA: Y <dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel</dd>
Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel <dt>Prefix:</dt>
Prefix: iana-dots-signal <dd>dots-signal</dd>
Reference: RFCXXXX <dt>Reference:</dt>
]]></artwork> <dd>[RFC9132]</dd>
</figure></t> </dl>
<t>This document obsoletes the initial version of the IANA-maintained
<t>This document defines the initial version of the IANA-maintained iana-dots-signal-channel YANG module (<xref target="RFC8782"
iana-dots-signal-channel YANG module. IANA is requested to maintain sectionFormat="of" section="5.2"/>). IANA is requested to maintain
this note:<list style="empty"> this note:</t>
<t>Status, conflict status, conflict cause, and attack status <t indent="5">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.</t>
</list></t>
<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="16">
<t hangText="&quot;enum&quot;:">Replicates the label from the <dt>"enum":</dt>
registry.</t> <dd>Replicates the label from the
registry.</dd>
<t hangText="&quot;value&quot;:">Contains the IANA-assigned value <dt>"value":</dt>
<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.</t> from the registry.</dd>
<dt>"reference":</dt>
<t hangText="&quot;reference&quot;:">Replicates the reference from <dd>Replicates the reference from
the registry and adds the title of the document.</t> the registry and adds the title of the document.</dd>
</list></t> </dl>
<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 has updated this note in "DOTS Status Codes", "DOTS
<t>IANA is requested to update this note of "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>
<t indent="5">When this registry is modified, the YANG module
<t><list style="empty">
<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> [RFC9132].</t>
</list></t>
</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 target="RFC8811"></xref>.</t> "RFC8612" format="default"/> and <xref target="RFC8811" format="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 Authentication Option (TCP-AO) <xref target="RFC5925"></xref>. 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 Although not widely adopted, if TCP-AO is used, then any bogus packets
injected by an attacker will be rejected by the TCP-AO integrity check injected by an attacker will be rejected by the TCP-AO integrity check
and therefore will never reach the TLS layer.</t> and therefore will never reach the TLS layer.</t>
<t>If the 'cuid' is guessable, a misbehaving DOTS client from within the <t>If the 'cuid' is guessable, a misbehaving DOTS client from within the
client's domain can use the 'cuid' of another DOTS client of the domain client's domain can use the 'cuid' of another DOTS client of the domain
to delete or alter active mitigations. For this attack to succeed, the to delete or alter active mitigations. For this attack to succeed, the
misbehaving client's messages need to pass the security validation misbehaving client's messages need to pass the security validation
checks by the DOTS server and, if the communication involves a checks by the DOTS server and, if the communication involves a
client-domain DOTS gateway, the security checks of that gateway.</t> client-domain DOTS gateway, the security checks of that 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 that
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" sectionFormat="of" section="4.4"/> are used to gene rate 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 a <t>A compromised DOTS client can collude with a DDoS attacker to send a
mitigation request for a target resource, get the mitigation efficacy mitigation request for a target resource, get the mitigation efficacy
from the DOTS server, and convey 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 (e.g., firewall), and a compromised security service potentially can do
a lot more damage to the network.</t> a 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 defend 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 client's <t>In order to prevent leaking internal information outside a client's
domain, DOTS gateways located in the client domain SHOULD NOT reveal the domain, DOTS gateways located in the client domain <bcp14>SHOULD NOT</bcp1 4> reveal the
identification information that pertains to internal DOTS clients (e.g., identification information that pertains to internal DOTS clients (e.g.,
source IP address, client's hostname) unless explicitly configured to do source IP address, client's hostname) unless explicitly configured to do
so.</t> 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. A DOTS server MUST NOT authorize trigger actions on a given IP prefix. A DOTS server <bcp14>MUST NOT</bcp14
> authorize
actions due to a DOTS client request unless those actions are limited to actions due to a DOTS client request unless those actions are limited to
that DOTS client's domain IP resources. The exact mechanism for the DOTS that DOTS client's domain IP resources. The exact mechanism for the DOTS
servers to validate that the target prefixes are within the scope of the servers to validate that the target prefixes are within the scope of the
DOTS client domain is deployment specific.</t> DOTS client domain is 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 DNS over HTTPS (DoH) <xref at="default"/> or DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/>
target="RFC8484"></xref>) to prevent eavesdroppers from possibly ) to prevent eavesdroppers from possibly
identifying the target resources protected by the DDoS mitigation identifying the target resources protected by the DDoS mitigation
service to ensure the target FQDN resolution is authentic (e.g., DNSSEC service to ensure the target FQDN resolution is authentic (e.g., DNSSEC
<xref target="RFC4034"></xref>).</t> <xref target="RFC4034" format="default"/>).</t>
<t>CoAP-specific security considerations are discussed in
<t>CoAP-specific security considerations are discussed in Section 11 of <xref target="RFC7252" sectionFormat="of" section="11"/>, while CBOR-relat
<xref target="RFC7252"></xref>, while CBOR-related security ed security
considerations are discussed in Section 10 of <xref considerations are discussed in <xref target="RFC8949" sectionFormat="of"
target="RFC8949"></xref>.</t> section="10"/>.</t>
<t>This document defines YANG data structures that are meant to be used <t>This document defines YANG data structures that are meant to be used
as an abstract representation of DOTS signal channel messages. As such, as an abstract representation of DOTS signal channel messages. As such,
the "ietf-dots-signal-channel" module does not introduce any new the "ietf-dots-signal-channel" module does not introduce any new
vulnerabilities beyond those specified above.</t> vulnerabilities beyond those specified above.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8791'?>
<?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.8949"?>
<?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.6020'?>
<?rfc include='reference.RFC.0791'?>
<?rfc include='reference.RFC.8768'?>
<?rfc include='reference.RFC.8783'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4732"?>
<?rfc include='reference.I-D.ietf-dots-telemetry'?>
<?rfc include='reference.RFC.8782'?>
<?rfc include='reference.RFC.7951'?>
<reference anchor="IANA-MediaTypes"
target="https://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="https://www.iana.org/assignments/core-parameters/core-p
arameters.xhtml#content-formats">
<front>
<title>CoAP Content-Formats</title>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
<reference anchor="IANA-CBOR-Tags"
target="https://www.iana.org/assignments/cbor-tags/cbor-tags.xh
tml">
<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.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'?> <displayreference target="I-D.ietf-dots-telemetry" to="DOTS-TELEMETRY"/>
<displayreference target="I-D.ietf-dots-multihoming" to="DOTS-MULTIHOMING"/>
<?rfc include='reference.RFC.4787'?> <displayreference target="I-D.ietf-core-yang-cbor" to="CORE-YANG-CBOR"/>
<displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/>
<?rfc include='reference.RFC.4340'?> <displayreference target="I-D.boucadair-dots-earlydata" to="DOTS-EARLYDATA"/>
<displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.8340'?>
<?rfc include='reference.RFC.6838'?>
<?rfc include='reference.I-D.ietf-dots-multihoming'?> <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.8791.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.8949.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.6020.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"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8783.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4732.xml"/>
<?rfc include="reference.I-D.ietf-core-yang-cbor"?> <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dots-telemetry
.xml"/>
<?rfc include="reference.I-D.ietf-core-comi"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8782.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7951.xml"/>
<?rfc include="reference.RFC.8612"?> <reference anchor="IANA-MediaTypes" target="https://www.iana.org/assignm
ents/media-types">
<front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<?rfc include="reference.RFC.8903"?> <reference anchor="IANA-CoAP-Content-Formats" target="https://www.iana.o
rg/assignments/core-parameters">
<front>
<title>CoAP Content-Formats</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<?rfc include="reference.RFC.8811"?> <reference anchor="IANA-CBOR-Tags" target="https://www.iana.org/assignme
nts/cbor-tags">
<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.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"/>
<?rfc include="reference.I-D.ietf-tls-dtls13"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-dots-multihoming.xml"/>
<?rfc include='reference.RFC.8973'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-core-yang-cbor.xml"/>
<?rfc include='reference.RFC.6887'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-core-comi.xml"/>
<?rfc include='reference.I-D.boucadair-dots-earlydata'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8903.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8811.xml"/>
<?rfc include='reference.RFC.8489'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-tls-dtls13.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6887.xml"/>
<reference anchor="IANA-Proto" <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
target="https://www.iana.org/assignments/protocol-numbers"> .boucadair-dots-earlydata.xml"/>
<front>
<title>Protocol Numbers</title>
<author fullname="IANA"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization></organization> FC.8489.xml"/>
</author>
<date year="2011" /> <reference anchor="IANA-Proto" target="https://www.iana.org/assignments/
</front> protocol-numbers">
</reference> <front>
<title>Protocol Numbers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="REG-DOTS" <reference anchor="REG-DOTS" target="https://www.iana.org/assignments/do
target="https://www.iana.org/assignments/dots/dots.xhtml"> ts">
<front> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) <title>Distributed Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel</title> Signal Channel</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<author fullname="IANA"> <reference anchor="URI" target="https://www.iana.org/assignments/well-kn
<organization></organization> own-uris">
</author> <front>
<title>Well-Known URIs</title>
<date /> <author>
</front> <organization>IANA</organization>
</reference> </author>
</front>
<reference anchor="URI" </reference>
target="https://www.iana.org/assignments/well-known-uris/well-k </references>
nown-uris.xhtml">
<front>
<title>Well-Known URIs</title>
<author fullname="IANA">
<organization></organization>
</author>
<date />
</front>
</reference>
</references> </references>
<section anchor="changes" numbered="true" toc="default">
<section anchor="changes" title="Summary of Changes From RFC8782"> <name>Summary of Changes From RFC 8782</name>
<t>The main changes compared to <xref target="RFC8782"></xref> are as <t>The main changes compared to <xref target="RFC8782" format="default"/>
are as
follows:</t> follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Update the "ietf-dots-signal-channel" YANG module (<xref <t>Update the "ietf-dots-signal-channel" YANG module (<xref target="yr
target="yrequest"></xref>) and the tree structure (<xref equest" format="default"/>) and the tree structure (<xref target="tree" format="
target="tree"></xref>) to follow the new YANG data structure default"/>) to follow the new YANG data structure
specified in <xref target="RFC8791"></xref>. In particular: <list specified in <xref target="RFC8791" format="default"/>. In particular:
style="symbols"> </t>
<t>Add in 'choice' to indicate the communication direction in <ul spacing="normal">
<li>Add in 'choice' to indicate the communication direction in
which a data node applies. If no 'choice' is indicated, a data which a data node applies. If no 'choice' is indicated, a data
node can appear in both directions (i.e., from DOTS clients to node can appear in both directions (i.e., from DOTS clients to
DOTS servers and vice versa).</t> DOTS servers and vice versa).</li>
<li>Remove 'config' clauses. Note that 'config' statements will
<t>Remove 'config' clauses. Note that 'config' statements will be ignored (if present) anyway, according to <xref target="RFC8791
be ignored (if present) anyway according to Section 4 of <xref "
target="RFC8791"></xref>. This supersedes the references to the sectionFormat="of" section="4"/>. This supersedes the references to
use of 'ro' and 'rw' which are now covered by 'choice' the
above.</t> use of 'ro' and 'rw', which are now covered by 'choice'
above.</li>
<t>Remove 'cuid', 'cdid', and 'sid' data nodes from the <li>Remove 'cuid', 'cdid', and 'sid' data nodes from the
structure because these data nodes are included as Uri-Path structure because these data nodes are included as Uri-Path
options, not within the message body.</t> options, not within the message body.</li>
<li>Remove the list keys for the mitigation scope message type
<t>Remove the list keys for the mitigation scope message type
(i.e., 'cuid' and 'mid'). 'mid' is not indicated as a key (i.e., 'cuid' and 'mid'). 'mid' is not indicated as a key
because it is included as Uri-Path option for requests and in because it is included as a Uri-Path option for requests and in
the message body for responses. Note that Section 4 of <xref the message body for responses. Note that <xref target="RFC8791"
target="RFC8791"></xref> specifies that a list does not require sectionFormat="of" section="4"/> specifies that a list does not req
to have a key statement defined.</t> uire
</list></t> to have a key statement defined.</li>
</ul>
<t>Add a new section with a summary of the error code responses that </li>
can be returned by a DOTS server (<xref <li>Add a new section with a summary of the error code responses that
target="errors"></xref>).</t> can be returned by a DOTS server (<xref target="errors" format="defaul
t"/>).</li>
<t>Update the IANA section to allocate a new range for <li>Update the IANA section to allocate a new range for
comprehension-optional attributes (<xref target="format"></xref>). comprehension-optional attributes (<xref target="format" format="defau
lt"/>).
This modification is motivated by the need to allow for compact DOTS This modification is motivated by the need to allow for compact DOTS
signal messages that include a long list of comprehension-optional signal messages that include a long list of comprehension-optional
attributes, e.g., DOTS telemetry messages <xref attributes, e.g., DOTS telemetry messages <xref target="I-D.ietf-dots-
target="I-D.ietf-dots-telemetry"></xref>.</t> telemetry"
format="default"/>.</li>
<t>Add <xref target="def"></xref> to list recommended/default values <li>Add <xref target="def" format="default"/> to list recommended/defaul
of key DOTS signal channel parameters.</t> t values
of key DOTS signal channel parameters.</li>
<t>Add subsections to Section 4.4.1 for better readability.</t> <li>Add subsections to <xref target="post" format="default"/> for better
</list></t> readability.</li>
</ul>
<t></t>
</section> </section>
<section anchor="motiv" numbered="true" toc="default">
<section anchor="motiv" title="CUID Generation"> <name>CUID Generation</name>
<t>The document recommends the use of SPKI to generate the 'cuid'. This <t>The document recommends the use of SPKI to generate the 'cuid'. This
design choice is motivated by the following reasons:<list design choice is motivated by the following reasons:</t>
style="symbols"> <ul spacing="normal">
<t>SPKI is globally unique.</t> <li>SPKI is globally unique.</li>
<li>It is deterministic.</li>
<t>It is deterministic.</t> <li>It allows the avoidance of extra cycles that may be induced by
'cuid' collision.</li>
<t>It allows the avoidance of extra cycles that may be induced by <li>DOTS clients do not need to store the 'cuid' in a persistent
'cuid' collision.</t> storage.</li>
<li>It allows the detection of compromised DOTS clients that do not
<t>DOTS clients do not need to store the 'cuid' in a persistent adhere to the 'cuid' generation algorithm.</li>
storage.</t> </ul>
<t>It allows the detection of compromised DOTS clients that do not
adhere to the 'cuid' generation algorithm.</t>
</list></t>
<t></t>
</section> </section>
<section anchor="def" numbered="true" toc="default">
<section anchor="def" <name>Summary of Protocol Recommended/Default Values</name>
title="Summary of Protocol Recommended/Default Values"> <table align="center">
<t></t> <thead>
<tr>
<texttable> <th align="left">Parameter</th>
<ttcol>Parameter</ttcol> <th align="left">Recommended/Default Value</th>
</tr>
<ttcol>Recommended/Default Value</ttcol> </thead>
<tbody>
<c>Port number</c> <tr>
<td align="left">Port number</td>
<c>4646 (tcp/udp)</c> <td align="left">4646 (tcp/udp)</td>
</tr>
<c>lifetime</c> <tr>
<td align="left">lifetime</td>
<c>3600 seconds</c> <td align="left">3600 seconds</td>
</tr>
<c>active-but-terminating</c> <tr>
<td align="left">active-but-terminating</td>
<c>120 seconds</c> <td align="left">120 seconds</td>
</tr>
<c>maximum active-but-terminating</c> <tr>
<td align="left">maximum active-but-terminating</td>
<c>300 seconds</c> <td align="left">300 seconds</td>
</tr>
<c>heartbeat-interval</c> <tr>
<td align="left">heartbeat-interval</td>
<c>30 seconds</c> <td align="left">30 seconds</td>
</tr>
<c>minimum 'heartbeat-interval'</c> <tr>
<td align="left">minimum 'heartbeat-interval'</td>
<c>15 seconds</c> <td align="left">15 seconds</td>
</tr>
<c>maximum 'heartbeat-interval'</c> <tr>
<td align="left">maximum 'heartbeat-interval'</td>
<c>240 seconds</c> <td align="left">240 seconds</td>
</tr>
<c>missing-hb-allowed</c> <tr>
<td align="left">missing-hb-allowed</td>
<c>15</c> <td align="left">15</td>
</tr>
<c>max-retransmit</c> <tr>
<td align="left">max-retransmit</td>
<c>3</c> <td align="left">3</td>
</tr>
<c>ack-timeout</c> <tr>
<td align="left">ack-timeout</td>
<c>2 seconds</c> <td align="left">2 seconds</td>
</tr>
<c>ack-random-factor</c> <tr>
<td align="left">ack-random-factor</td>
<c>1.5</c> <td align="left">1.5</td>
</tr>
<c>probing-rate</c> <tr>
<td align="left">probing-rate</td>
<c>5 bytes/second</c> <td align="left">5 bytes/second</td>
</tr>
<c>trigger-mitigation</c> <tr>
<td align="left">trigger-mitigation</td>
<c>true</c> <td align="left">true</td>
</texttable> </tr>
</tbody>
</table>
</section> </section>
<section anchor="ack" numbered="false" toc="default">
<section anchor="ack" title="Acknowledgements"> <name>Acknowledgements</name>
<t>Many thanks to Martin Bj&ouml;rklund for the suggestion to use <t>Many thanks to <contact fullname="Martin Björklund"/> for the suggestio
RFC8791.</t> n to use
<xref target="RFC8791" format="default"/>.</t>
<t>Thanks to Valery Smyslov for the comments, guidance, and support.</t> <t>Thanks to <contact fullname="Valery Smyslov"/> for the comments, guidan
ce, and
<t>Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for support.</t>
the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley <t>Thanks to <contact fullname="Ebben Aries"/> for the yangdoctors review,
for the genart review, and Donald Eastlake for the secdir review.</t> <contact fullname="Dan Romascanu"/> for
the opsdir review, <contact fullname="Michael Tuexen"/> for the tsv-art re
<t>Thanks to Benjamin Kaduk for the AD review.</t> view,
<contact fullname="Dale Worley"/>
<t>Thanks to Martin Duke, Lars Eggert, Erik Kline, Murray Kucherawy, for the genart review, and <contact fullname="Donald Eastlake 3rd"/> for t
&Eacute;ric Vyncke, and Robert Wilton for the IESG review.</t> he secdir
review.</t>
<section title="Acknowledgements from RFC8782"> <t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
<t>Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, <t>Thanks to <contact fullname="Martin Duke"/>, <contact fullname="Lars Eg
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang gert"/>,
Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, <contact fullname="Erik Kline"/>, <contact fullname="Murray Kucherawy"/>,
Nesredien Suleiman, Stephen Farrell, and Yoshifumi Nishida for the <contact fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/>
discussion and comments.</t> for the IESG review.</t>
<section numbered="false" toc="exclude">
<t>The authors would like to give special thanks to Kaname Nishizuka <name>Acknowledgements from RFC 8782</name>
and Jon Shallow for their efforts in implementing the protocol and <t>Thanks to <contact fullname="Christian Jacquenet"/>, <contact
fullname="Roland Dobbins"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Michael Richardson"/>, <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 Farrell"/>, and <contact fullname="Yoshifumi N
ishida"/>
for the discussion and comments.</t>
<t>The authors would like to give special thanks to <contact
fullname="Kaname Nishizuka"/> and <contact fullname="Jon Shallow"/>
for their efforts in implementing the protocol 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 detail
<t>Special thanks to Benjamin Kaduk for the detailed AD review.</t> ed AD review.</t>
<t>Thanks to <contact fullname="Alexey Melnikov"/>, <contact fullname="A
<t>Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja dam Roach"/>,
K&uuml;hlewind, and Alissa Cooper for the review.</t> <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kuehlewin
d"/>, 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
DOTS heartbeat
mechanism.</t> mechanism.</t>
</section> </section>
</section> </section>
<section anchor="contr" numbered="false" toc="default">
<name>Contributors</name>
<t>The authors of RFC 8782 are listed below:</t>
<contact fullname="Tirumaleswar Reddy.K (editor)">
<organization>McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<code>560071</code>
<region>Karnataka</region>
<country>India</country>
</postal>
<email>kondtir@gmail.com</email>
</address>
</contact>
<section anchor="contr" title="Contributors"> <contact fullname="Mohamed Boucadair (editor)">
<t></t> <organization>Orange</organization>
<address>
<section title="Authors of RFC8782"> <postal>
<t>The authors of RFC8782 are listed below:</t> <city>Rennes</city>
<code>35000</code>
<t><figure> <country>France</country>
<artwork><![CDATA[ Tirumaleswar Reddy.K (editor) </postal>
McAfee, Inc. <email>mohamed.boucadair@orange.com</email>
Embassy Golf Link Business Park </address>
Bangalore 560071 </contact>
Karnataka
India
Email: kondtir@gmail.com
Mohamed Boucadair (editor)
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Andrew Mortensen
Arbor Networks, Inc.
2727 S. State Street
Ann Arbor, MI 48104
United States of America
Email: andrew@moretension.com
Nik Teague
Iron Mountain Data Centers
United Kingdom
Email: nteague@ironmountain.co.uk]]></artwork>
</figure></t>
</section>
<section title="Contributors to RFC8782">
<t>The following individuals have contributed to RFC8782:<figure>
<artwork><![CDATA[ Jon Shallow
NCC Group
Email: jon.shallow@nccgroup.trust <contact fullname="Prashanth Patil">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>praspati@cisco.com</email>
</address>
</contact>
Mike Geller <contact fullname="Andrew Mortensen">
Cisco Systems, Inc. <organization>Arbor Networks, Inc.</organization>
FL 33309 <address>
United States of America <postal>
<street>2727 S. State Street</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48104</code>
<country>United States of America</country>
</postal>
<email>andrew@moretension.com</email>
</address>
</contact>
Email: mgeller@cisco.com <contact fullname="Nik Teague">
<organization>Iron Mountain Data Centers</organization>
<address>
<postal>
<country>United Kingdom</country>
</postal>
<email>nteague@ironmountain.co.uk</email>
</address>
</contact>
<t>The following individuals have contributed to RFC 8782:</t>
<contact fullname="Jon Shallow">
<organization>NCC Group</organization>
<address>
<email>jon.shallow@nccgroup.trust</email>
</address>
</contact>
Robert Moskowitz <contact fullname="Mike Geller">
HTT Consulting <organization>Cisco Systems, Inc.</organization>
Oak Park, MI 42837 <address>
United States of America <postal>
<region>FL</region>
<code>33309</code>
<country>United States of America</country>
</postal>
<email>mgeller@cisco.com</email>
</address>
</contact>
Email: rgm@htt-consult.com]]></artwork> <contact fullname="Robert Moskowitz">
</figure></t> <organization>HTT Consulting</organization>
<address>
<postal>
<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>
</section> </section>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 652 change blocks. 
2701 lines changed or deleted 3256 lines changed or added

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