rfc9133xml2.original.xml   rfc9133.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" category="std"
<?rfc tocdepth="4"?> consensus="true" number="9133" docName="draft-ietf-dots-signal-filter-contr
<?rfc tocindent="yes"?> ol-07"
<?rfc symrefs="yes"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
<?rfc sortrefs="yes"?> xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
<?rfc comments="yes"?> sortRefs="true" version="3">
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dots-signal-filter-control-07"
ipr="trust200902">
<front> <front>
<title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules <title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules
Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel</title> Channel</title>
<seriesInfo name="RFC" value="9133"/>
<author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka"> <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
<organization>NTT Communications</organization> <organization>NTT Communications</organization>
<address> <address>
<postal> <postal>
<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street> <street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
<code>108-8118</code>
<city>Tokyo</city> <region>Tokyo</region>
<region></region>
<code>108-8118</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>kaname@nttv6.jp</email> <email>kaname@nttv6.jp</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<region/>
<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="Tirumaleswar Reddy" initials="T." surname="Reddy"> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization abbrev="Akamai">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>
<code>560071</code> <code>560071</code>
<region>Karnataka</region>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Takahiko Nagata" initials="T." surname="Nagata"> <author fullname="Takahiko Nagata" initials="T." surname="Nagata">
<organization>Lepidum</organization> <organization>Lepidum</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>nagata@lepidum.co.jp</email> <email>nagata@lepidum.co.jp</email>
</address> </address>
</author> </author>
<date month="September" year="2021"/>
<date />
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>Mitigation</keyword> <keyword>Mitigation</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Filtering</keyword> <keyword>Filtering</keyword>
<keyword>Protective Networking</keyword> <keyword>Protective Networking</keyword>
<keyword>Protected Networks</keyword> <keyword>Protected Networks</keyword>
<keyword>Security</keyword> <keyword>Security</keyword>
<keyword>Anti-DDoS</keyword> <keyword>Anti-DDoS</keyword>
<keyword>Reactive</keyword> <keyword>Reactive</keyword>
<keyword>Collaborative Networking</keyword> <keyword>Collaborative Networking</keyword>
<keyword>Collaborative Security</keyword> <keyword>Collaborative Security</keyword>
<abstract> <abstract>
<t>This document specifies an extension to the Distributed <t>This document specifies an extension to the Distributed
Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol
so that DOTS clients can control their filtering rules when an attack so that DOTS clients can control their filtering rules when an attack
mitigation is active.</t> mitigation is active.</t>
<t>Particularly, this extension allows a DOTS client to activate or <t>Particularly, this extension allows a DOTS client to activate or
de-activate existing filtering rules during a DDoS attack. The deactivate existing filtering rules during a Distributed
Denial-of-Service (DDoS) attack. The
characterization of these filtering rules is conveyed by a DOTS client characterization of these filtering rules is conveyed by a DOTS client
during an idle time (i.e., no mitigation is active) by means of the DOTS during an 'idle' time (i.e., no mitigation is active) by means of the DOTS
data channel protocol.</t> data channel protocol.</t>
</abstract> </abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within the document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal Channel";</t>
<t>reference: RFC XXXX</t>
<t>[RFCXXXX]</t>
</list>Please update the "revision" date of the YANG module.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<section anchor="problem" title="The Problem"> <name>Introduction</name>
<section anchor="problem" numbered="true" toc="default">
<name>The Problem</name>
<t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS) <t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
architecture <xref target="I-D.ietf-dots-architecture"></xref>, DOTS architecture <xref target="RFC8811" format="default"/>, DOTS
clients and servers communicate using both a signal channel protocol clients and servers communicate using both a signal channel protocol
<xref target="RFC8782"></xref> and a data channel protocol <xref <xref target="RFC9132" format="default"/> and a data channel protocol <x
target="RFC8783"></xref>.</t> ref target="RFC8783" format="default"/>.</t>
<t>The DOTS data channel protocol <xref target="RFC8783"></xref> is
used for bulk data exchange between DOTS agents to improve the
coordination of parties involved in the response to a Distributed
Denial-of-Service (DDoS) attack. Filter management is one of its tasks
which enables a DOTS client to retrieve the filtering capabilities of
a DOTS server and to manage filtering rules. Typically, these
filtering rules are used for dropping or rate-limiting unwanted
traffic, and permitting accept-listed traffic.</t>
<t>The DOTS signal channel protocol <xref target="RFC8782"></xref> is <t>The DOTS data channel protocol <xref target="RFC8783"
format="default"/> is used for bulk data exchange between DOTS agents
to improve the coordination of parties involved in the response to a
Distributed Denial-of-Service (DDoS) attack. Filter management, which
is one of the tasks of the DOTS data channel protocol, enables a DOTS
client to retrieve the filtering capabilities of a DOTS server and to
manage filtering rules. Typically, these filtering rules are used for
dropping or rate-limiting unwanted traffic, and permitting
accept-listed traffic.</t>
<t>The DOTS signal channel protocol <xref target="RFC9132" format="defau
lt"/> is
designed to be resilient under extremely hostile network conditions designed to be resilient under extremely hostile network conditions
and provides continued contact between DOTS agents even as DDoS attack and provides continued contact between DOTS agents even as DDoS attack
traffic saturates the link. The DOTS signal channel can be established traffic saturates the link. The DOTS signal channel can be established
between two DOTS agents prior to or during an attack. At any time, the between two DOTS agents prior to or during an attack. At any time, the
DOTS client may send mitigation requests (as per Section 4.4 of <xref DOTS client may send mitigation requests (as per <xref
target="RFC8782"></xref>) to a DOTS server over the active signal target="RFC9132" sectionFormat="of" section="4.4"/>) to a DOTS server ove
r the active signal
channel. While mitigation is active, the DOTS server periodically channel. While mitigation is active, the DOTS server periodically
sends status messages to the DOTS client, including basic mitigation sends status messages to the DOTS client, including basic mitigation
feedback details. In case of a massive DDoS attack that saturates the feedback details. In case of a massive DDoS attack that saturates the
incoming link(s) to the DOTS client, all traffic from the DOTS server incoming link(s) to the DOTS client, all traffic from the DOTS server
to the DOTS client will likely be dropped. However, the DOTS server to the DOTS client will likely be dropped. However, the DOTS server
may still receive DOTS messages sent from the DOTS client over the may still receive DOTS messages sent from the DOTS client over the
signalling channel thanks to the heartbeat requests keeping the signaling channel thanks to the heartbeat requests keeping the
channel active (as described in Section 4.7 of <xref channel active (as described in <xref target="RFC9132"
target="RFC8782"></xref>).</t> sectionFormat="of" section="4.7"/>).</t>
<t>Unlike the DOTS signal channel protocol, the DOTS data channel <t>Unlike the DOTS signal channel protocol, the DOTS data channel
protocol is not expected to deal with attack conditions. As such, an protocol is not expected to deal with attack conditions. As such, an
issue that might be encountered in some deployments is when filters issue that might be encountered in some deployments is when filters
installed by means of the DOTS data channel protocol may not function installed by means of the DOTS data channel protocol may not function
as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
attack. In such conditions the DOTS data channel protocol cannot be attack. In such conditions, the DOTS data channel protocol cannot be
used to change these filters, which may complicate DDoS mitigation used to change these filters, which may complicate DDoS mitigation
operations <xref target="Interop"></xref>.</t> operations <xref target="INTEROP" format="default"/>.</t>
<t>A typical case is a conflict between filtering rules installed by a <t>A typical case is a conflict between filtering rules installed by a
DOTS client and the mitigation actions of a DDoS mitigator. Consider, DOTS client and the mitigation actions of a DDoS mitigator. Consider,
for instance, a DOTS client that configures during 'idle' time (i.e., for instance, a DOTS client that configures during 'idle' time (i.e.,
no mitigation is active) some filtering rules using the DOTS data no mitigation is active) some filtering rules using the DOTS data
channel protocol to permit traffic from accept-listed sources. channel protocol to permit traffic from accept-listed sources.
However, during a volumetric DDoS attack the DDoS mitigator identifies However, during a volumetric DDoS attack, the DDoS mitigator identifies
the source addresses/prefixes in the accept-listed filtering rules are the source addresses/prefixes in the accept-listed filtering rules are
attacking the target. For example, an attacker can spoof the IP attacking the target. For example, an attacker can spoof the IP
addresses of accept-listed sources to generate attack traffic or the addresses of accept-listed sources to generate attack traffic, or the
attacker can compromise the accept-listed sources and program them to attacker can compromise the accept-listed sources and program them to
launch a DDoS attack.</t> launch a DDoS attack.</t>
<t><xref target="RFC8782"></xref> is designed so that the DDoS server <t><xref target="RFC9132" format="default"/> is designed so that the
notifies the above conflict to the DOTS client (that is, DDoS server notifies the above conflict to the DOTS client (that is,
'conflict-cause' parameter set to 2 (Conflicts with an existing accept the 'conflict-cause' parameter is set to 2 (conflict-with-acceptlist)),
list)), but the DOTS client may not be able to withdraw the but the DOTS client may not be able to withdraw the accept-list rules
accept-list rules during the attack period due to the high-volume during the attack period due to the high-volume attack traffic
attack traffic saturating the inbound link to the DOTS client domain. saturating the inbound link to the DOTS client domain. In other
In other words, the DOTS client cannot use the DOTS data channel words, the DOTS client cannot use the DOTS data channel protocol to
protocol to withdraw the accept-list filters when a DDoS attack is in withdraw the accept-list filters when a DDoS attack is in
progress.</t> progress.</t>
</section>
<section anchor="sol" </section>
title="Controlling Filtering Rules Using DOTS Signal Channel"> <section anchor="sol" numbered="true" toc="default">
<t>This specification addresses the problems discussed in <xref <name>Controlling Filtering Rules Using DOTS Signal Channel</name>
target="problem"></xref> by adding a capability for managing filtering <t>This specification addresses the problems discussed in <xref target="
problem" format="default"/> by adding a capability for managing filtering
rules using the DOTS signal channel protocol, which enables a DOTS rules using the DOTS signal channel protocol, which enables a DOTS
client to request the activation (or deactivation) of filtering rules client to request the activation (or deactivation) of filtering rules
during a DDoS attack. Note that creating these filtering rules is during a DDoS attack. Note that creating these filtering rules is
still the responsibility of the DOTS data channel <xref still the responsibility of the DOTS data channel <xref target="RFC8783"
target="RFC8783"></xref>.</t> format="default"/>.</t>
<t>The DOTS signal channel protocol is designed to enable a DOTS <t>The DOTS signal channel protocol is designed to enable a DOTS
client to contact a DOTS server for help even under severe network client to contact a DOTS server for help even under severe network
congestion conditions. Therefore, extending the DOTS signal channel congestion conditions. Therefore, extending the DOTS signal channel
protocol to manage the filtering rules during an attack will enhance protocol to manage the filtering rules during an attack will enhance
the protection capability offered by DOTS protocols.</t> the protection capability offered by DOTS protocols.</t>
<t><list style="empty"> <aside>
<t>Note: The experiment at the IETF103 hackathon <xref <t>Note: The experiment at the IETF 103 hackathon <xref
target="Interop"></xref> showed that even when the inbound link is target="INTEROP" format="default"/> showed that even when the
saturated by DDoS attack traffic, the DOTS client can signal inbound link is saturated by DDoS attack traffic, the DOTS client
mitigation requests using the DOTS signal channel over the can signal mitigation requests using the DOTS signal channel over
saturated link.</t> the saturated link.</t>
</list></t> </aside>
<t>Conflicts that are induced by filters installed by other DOTS <t>Conflicts that are induced by filters installed by other DOTS
clients of the same domain are not discussed in this clients of the same domain are not discussed in this
specification.</t> specification.</t>
<t>An augmentation to the DOTS signal channel YANG module is defined <t>An augmentation to the DOTS signal channel YANG module is defined
in <xref target="YANG"></xref>.</t> in <xref target="YANG" format="default"/>.</t>
<t>Sample examples are provided in <xref target="sample" format="default
<t>Sample examples are provided in <xref target="sample"></xref>, in "/>, in
particular: <list style="symbols"> particular: </t>
<t><xref target="sample1"></xref> illustrates how the filter <ul spacing="normal">
<li>
<xref target="sample1" format="default"/> illustrates how the filter
control extension is used when conflicts with Access Control Lists control extension is used when conflicts with Access Control Lists
(ACLs) are detected and reported by a DOTS server.</t> (ACLs) are detected and reported by a DOTS server.</li>
<li>
<t><xref target="sample2"></xref> shows how a DOTS client can <xref target="sample2" format="default"/> shows how a DOTS client ca
n
instruct a DOTS server to safely forward some specific traffic in instruct a DOTS server to safely forward some specific traffic in
'attack' time.</t> 'attack' time.</li>
<li>
<t><xref target="sample3"></xref> shows how a DOTS client can <xref target="sample3" format="default"/> shows how a DOTS client ca
n
react if the DDoS traffic is still being forwarded to the DOTS react if the DDoS traffic is still being forwarded to the DOTS
client domain even if mitigation requests were sent to a DOTS client domain even if mitigation requests were sent to a DOTS
server.</t> server.</li>
</list></t> </ul>
<t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data <t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data
<xref target="RFC7951"></xref> is used to illustrate the examples.</t> <xref target="RFC7951" format="default"/> is used to illustrate the exam ples.</t>
</section> </section>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="notation" title="Terminology"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
format="default"/> <xref target="RFC8174" format="default"/> when, and
only when, they appear in all capitals, as shown here.</t> only when, they appear in all capitals, as shown here.</t>
<t>The reader should be familiar with the terms defined in <xref <t>The reader should be familiar with the terms defined in <xref
target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
<t>The terminology for describing YANG modules is defined in <xref <t>The terminology for describing YANG modules is defined in <xref
target="RFC7950"></xref>. The meaning of the symbols in the tree diagram target="RFC7950" format="default"/>. The meaning of the symbols in the
is defined in <xref target="RFC8340"></xref>.</t> tree diagram is defined in <xref target="RFC8340"/> and <xref target="RFC8
791"
format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Controlling Filtering Rules of a DOTS Client"> <name>Controlling Filtering Rules of a DOTS Client</name>
<section anchor="bind" title="Binding DOTS Data and Signal Channels"> <section anchor="bind" numbered="true" toc="default">
<name>Binding DOTS Data and Signal Channels</name>
<t>The filtering rules eventually managed using the DOTS signal <t>The filtering rules eventually managed using the DOTS signal
channel protocol are created a priori by the same DOTS client using channel protocol are created a priori by the same DOTS client using
the DOTS data channel protocol. Managing conflicts with filters the DOTS data channel protocol. Managing conflicts with filters
installed by other DOTS clients of the same domain is out of installed by other DOTS clients of the same domain is out of
scope.</t> scope.</t>
<t>As discussed in <xref target="RFC9132" sectionFormat="of"
<t>As discussed in Section 4.4.1 of <xref target="RFC8782"></xref>, a section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the
DOTS client must use the same 'cuid' for both the DOTS signal and data DOTS signal and data channels. This requirement is meant to facilitate
channels. This requirement is meant to facilitate binding DOTS binding DOTS channels used by the same DOTS client.</t>
channels used by the same DOTS client.</t>
<t>The DOTS signal and data channels from a DOTS client may or may not <t>The DOTS signal and data channels from a DOTS client may or may not
use the same DOTS server. Nevertheless, the scope of the mitigation use the same DOTS server. Nevertheless, the scope of the mitigation
request, alias, and filtering rules are not restricted to the DOTS request, alias, and filtering rules are not restricted to the DOTS
server but to the DOTS server domain. To that aim, DOTS servers within server but to the DOTS server domain. To that aim, DOTS servers within
a domain are assumed to have a mechanism to coordinate the mitigation a domain are assumed to have a mechanism to coordinate the mitigation
requests, aliases, and filtering rules to coordinate their decisions requests, aliases, and filtering rules to coordinate their decisions
for better mitigation operation efficiency. The exact details about for better mitigation operation efficiency. The exact details about
such mechanism is out of the scope of this document.</t> such a mechanism is out of the scope of this document.</t>
<t>A filtering rule controlled by the DOTS signal channel is <t>A filtering rule controlled by the DOTS signal channel is
identified by its ACL name (Section 4.3 of <xref identified by its ACL name (<xref target="RFC8783"
target="RFC8782"></xref>). Note that an ACL name unambiguously sectionFormat="of" section="4.3"/>). Note that an ACL name unambiguously
identifies an ACL bound to a DOTS client, but the same name may be identifies an ACL bound to a DOTS client, but the same name may be
used by distinct DOTS clients.</t> used by distinct DOTS clients.</t>
<t>The activation or deactivation of an ACL by the DOTS signal channel <t>The activation or deactivation of an ACL by the DOTS signal channel
overrides the 'activation-type' (defined in Section 4.3 of <xref overrides the 'activation-type' (defined in <xref target="RFC8783"
target="RFC8783"></xref>) a priori conveyed with the filtering rules sectionFormat="of" section="4.3"/>) a priori conveyed with the
using the DOTS data channel protocol.</t> filtering rules using the DOTS data channel protocol.</t>
<t>Once the attack is mitigated, the DOTS client may use the data <t>Once the attack is mitigated, the DOTS client may use the data
channel to control the 'activation-type' (e.g., revert to a default channel to control the 'activation-type' (e.g., revert to a default
value) of some of the filtering rules controlled by the DOTS signal value) of some of the filtering rules controlled by the DOTS signal
channel or delete some of these filters. This behavior is deployment channel or delete some of these filters. This behavior is deployment
specific.</t> specific.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Signal Channel Extension"> <name>DOTS Signal Channel Extension</name>
<section anchor="filtering" title="Parameters and Behaviors"> <section anchor="filtering" numbered="true" toc="default">
<name>Parameters and Behaviors</name>
<t>This specification extends the mitigation request defined in <t>This specification extends the mitigation request defined in
Section 4.4.1 of <xref target="RFC8782"></xref> to convey the <xref target="RFC9132" sectionFormat="of" section="4.4.1"/> to
intended control of configured filtering rules. Concretely, the DOTS convey the intended control of configured filtering
client conveys 'acl-list' attribute with the following rules. Concretely, the DOTS client conveys the 'acl-list' attribute wi
sub-attributes in the CBOR body of a mitigation request (see the th
YANG structure in <xref target="tree"></xref>):<list style="hanging"> the following sub-attributes in the Concise Binary Object
<t hangText="acl-name:">A name of an access list defined using Representation (CBOR) body of a mitigation
the DOTS data channel (Section 4.3 of <xref request (see the YANG structure in <xref target="tree"
target="RFC8783"></xref>) that is associated with the DOTS format="default"/>):</t>
client.<vspace blankLines="1" />As a reminder, an ACL is an <dl newline="false" spacing="normal">
ordered list of Access Control Entries (ACE). Each ACE has a <dt>acl-name:</dt>
list of match criteria and a list of actions <xref <dd>
target="RFC8783"></xref>. The list of configured ACLs can be <t>A name of an access list defined using
retrieved using the DOTS data channel during 'idle' time.<vspace the DOTS data channel (<xref target="RFC8783"
blankLines="1" />This is a mandatory attribute when 'acl-list' sectionFormat="of" section="4.3"/>) that is associated with the DOT
S
client.</t>
<t>As a reminder, an ACL is an ordered list of Access Control
Entries (ACEs). Each ACE has a list of match criteria and a list
of actions <xref target="RFC8783" format="default"/>. The list
of configured ACLs can be retrieved using the DOTS data channel
during 'idle' time.</t>
<t>This is a mandatory attribute when 'acl-list'
is included.</t> is included.</t>
</dd>
<t hangText="activation-type:">Indicates the activation type of <dt>activation-type:</dt>
<dd>
<t>An attribute indicating the activation type of
an ACL overriding the existing 'activation-type' installed by an ACL overriding the existing 'activation-type' installed by
the DOTS client using the DOTS data channel. <vspace the DOTS client using the DOTS data channel. </t>
blankLines="1" />As a reminder, this attribute can be set to <t>As a reminder, this attribute can be set to
'deactivate', 'immediate', or 'activate-when-mitigating' as 'deactivate', 'immediate', or 'activate-when-mitigating' as
defined in <xref target="RFC8783"></xref>. <vspace defined in <xref target="RFC8783" format="default"/>. </t>
blankLines="1" />Note that both 'immediate' and <t>Note that both 'immediate' and
'activate-when-mitigating' have an immediate effect when a 'activate-when-mitigating' have an immediate effect when a
mitigation request is being processed by the DOTS server. mitigation request is being processed by the DOTS server.
<vspace blankLines="1" />This is an optional attribute.</t> </t>
</list></t> <t>This is an optional attribute.</t>
</dd>
</dl>
<t>By default, ACL-related operations are achieved using the DOTS <t>By default, ACL-related operations are achieved using the DOTS
data channel protocol when no attack is ongoing. DOTS clients MUST data channel protocol when no attack is ongoing. DOTS clients <bcp14>M
NOT use the filtering control over DOTS signal channel in 'idle' UST
time; such requests MUST be discarded by DOTS servers with 4.00 (Bad NOT</bcp14> use the filtering control over the DOTS signal channel in
'idle'
time; such requests <bcp14>MUST</bcp14> be discarded by DOTS servers w
ith 4.00 (Bad
Request).</t> Request).</t>
<t>During an attack time, DOTS clients may include 'acl-list', <t>During an attack time, DOTS clients may include 'acl-list',
'acl-name', and 'activation-type' attributes in a mitigation 'acl-name', and 'activation-type' attributes in a mitigation
request. This request may be the initial mitigation request for a request. This request may be the initial mitigation request for a
given mitigation scope or a new one overriding an existing request. given mitigation scope or a new one overriding an existing request.
In both cases, a new 'mid' MUST be used. Nevertheless, it is NOT In both cases, a new 'mid' <bcp14>MUST</bcp14> be used. Nevertheless,
RECOMMENDED to include ACL attributes in an initial mitigation it is <bcp14>NOT
RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation
request for a given mitigation scope or in a mitigation request request for a given mitigation scope or in a mitigation request
adjusting the mitigation scope. This recommendation is meant to adjusting the mitigation scope. This recommendation is meant to
avoid delaying attack mitigations because of failures to process ACL avoid delaying attack mitigations because of failures to process ACL
attributes.</t> attributes.</t>
<t>As the attack evolves, DOTS clients can adjust the <t>As the attack evolves, DOTS clients can adjust the
'activation-type' of an ACL conveyed in a mitigation request or 'activation-type' of an ACL conveyed in a mitigation request or
control other filters as necessary. This can be achieved by sending control other filters as necessary. This can be achieved by sending
a PUT request with a new 'mid' value.</t> a PUT request with a new 'mid' value.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe
<t>It is RECOMMENDED for a DOTS client to subscribe to asynchronous to asynchronous notifications of the attack mitigation, as detailed
notifications of the attack mitigation, as detailed in Section in <xref target="RFC9132" sectionFormat="of" section="4.4.2.1"/>. If
4.4.2.1 of <xref target="RFC8782"></xref>. If not, the polling not, the polling mechanism in <xref target="RFC9132"
mechanism in Section 4.4.2.2 of <xref target="RFC8782"></xref> has sectionFormat="of" section="4.4.2.2"/> has to be followed by the
to be followed by the DOTS client.</t> DOTS client.</t>
<t>A DOTS client relies on the information received from the DOTS <t>A DOTS client relies on the information received from the DOTS
server and/or local information to the DOTS client domain to trigger server and/or local information to the DOTS client domain to trigger
a filter control request. Only filters that are pertinent for an a filter control request. Only filters that are pertinent for an
ongoing mitigation should be controlled by a DOTS client using the ongoing mitigation should be controlled by a DOTS client using the
DOTS signal channel.</t> DOTS signal channel.</t>
<t>'acl-list', 'acl-name', and 'activation-type' are defined as <t>'acl-list', 'acl-name', and 'activation-type' are defined as
comprehension-required parameters. Following the rules in Section 6 comprehension-required parameters. Following the rules in <xref
of <xref target="RFC8782"></xref>, if the DOTS server does not target="RFC9132" sectionFormat="of" section="6"/>, if the DOTS
understand the 'acl-list' or 'acl-name' or 'activation-type' server does not understand the 'acl-list', 'acl-name', or
attributes, it responds with a "4.00 (Bad Request)" error response 'activation-type' attributes, it responds with a 4.00 (Bad
code.</t> Request) error response code.</t>
<t>If the DOTS server does not find the ACL name ('acl-name') <t>If the DOTS server does not find the ACL name ('acl-name')
conveyed in the mitigation request for this DOTS client, it MUST conveyed in the mitigation request for this DOTS client, it <bcp14>MUS
respond with 4.04 (Not Found) error response code.</t> T</bcp14>
respond with a 4.04 (Not Found) error response code.</t>
<t>If the DOTS server finds the ACL name for this DOTS client, and <t>If the DOTS server finds the ACL name for this DOTS client, and
assuming the request passed the validation checks in Section 4.4.1 assuming the request passed the validation checks in <xref
of <xref target="RFC8782"></xref>, the DOTS server MUST proceed with target="RFC9132" sectionFormat="of" section="4.4.1"/>, the DOTS
the 'activation-type' update. The update is immediately enforced by server <bcp14>MUST</bcp14> proceed with the 'activation-type'
the DOTS server and will be maintained as the new activation type update. The update is immediately enforced by the DOTS server and
for the ACL name even after the termination of the mitigation will be maintained as the new activation type for the ACL name even
request. In addition, the DOTS server MUST update the lifetime of after the termination of the mitigation request. In addition, the
the corresponding ACL similar to the update when a refresh request DOTS server <bcp14>MUST</bcp14> update the lifetime of the
is received using the DOTS data channel (Section 7.2 of <xref corresponding ACL similar to the update when a refresh request is
target="RFC8783"></xref>). If, for some reason, the DOTS server received using the DOTS data channel (<xref target="RFC8783"
fails to apply the filter update, it MUST respond with 5.03 (Service sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS
Unavailable) error response code and include the failed ACL update server fails to apply the filter update, it <bcp14>MUST</bcp14>
in the diagnostic payload of the response (an example is shown in respond with a 5.03 (Service Unavailable) error response code and
<xref target="diag"></xref>). Else, the DOTS server replies with the include the failed ACL update in the diagnostic payload of the
appropriate response code defined in Section 4.4.1 of <xref response (an example is shown in <xref target="diag"
target="RFC8782"></xref>.</t> format="default"/>). Else, the DOTS server replies with the
appropriate response code defined in <xref target="RFC9132"
<t><figure align="center" anchor="diag" sectionFormat="of" section="4.4.1"/>.</t>
title="Example of a Diagnostic Payload Including Failed ACL Update <figure anchor="diag">
"> <name>Example of a Diagnostic Payload Including Failed ACL Update</n
<artwork><![CDATA[{ ame>
<sourcecode>
{
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 123, "mid": 123,
"ietf-dots-signal-control:acl-list": [ "ietf-dots-signal-control:acl-list": [
{ {
"acl-name": "an-accept-list", "acl-name": "an-accept-list",
"activation-type": "deactivate" "activation-type": "deactivate"
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> </sourcecode>
</figure>
<t>The JSON/YANG mappings for DOTS filter control attributes are <t>The JSON/YANG mappings for DOTS filter control attributes are
shown in Table 1. As a reminder, the mapping for 'acl-name' is shown in <xref target="table1"/>. As a reminder, the mapping for 'acl-
defined in Table 5 of <xref target="RFC8782"></xref>.</t> name' is
defined in Table 5 of <xref target="RFC9132"/>.</t>
<t><figure> <table anchor="table1">
<artwork><![CDATA[+-------------------+------------+--------+----- <name>JSON/YANG Mapping to CBOR for Filter Control Attributes</name>
----------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | <thead>
| | Type | Key | Type & | Type | <tr>
| | | | Information | | <th>Parameter Name</th>
+===================+============+========+===============+========+ <th>YANG Type</th>
| activation-type | enumeration| TBA1 | 0 unsigned | String | <th>CBOR Key</th>
+-------------------+------------+--------+---------------+--------+ <th>CBOR Major Type &amp; Information</th>
| ietf-dots-signal- | | | | | <th>JSON Type</th>
| control:acl-list | list | TBA2 | 4 array | Array | </tr>
+-------------------+------------+--------+---------------+--------+ </thead>
| acl-name | leafref | 23 | 3 text string | String | <tbody>
+-------------------+------------+--------+---------------+--------+ <tr>
Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes]]></artwork> <td>activation-type</td>
</figure></t> <td>enumeration</td>
<td>52</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>ietf-dots-signal-control:acl-list</td>
<td>list</td>
<td>53</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>
</tbody>
</table>
<t>If the DOTS client receives a 5.03 (Service Unavailable) with a <t>If the DOTS client receives a 5.03 (Service Unavailable) with a
diagnostic payload indicating a failed ACL update as a response to diagnostic payload indicating a failed ACL update as a response to
an initial mitigation or a mitigation with adjusted scope, the DOTS an initial mitigation or a mitigation with adjusted scope, the DOTS
client MUST immediately send a new request which repeats all the client <bcp14>MUST</bcp14> immediately send a new request that
parameters as sent in the failed mitigation request but without repeats all the parameters as sent in the failed mitigation request
including the ACL attributes. After the expiry of Max-Age returned but without including the ACL attributes. After the expiry of
in the 5.03 (Service Unavailable) response, the DOTS client retries Max-Age returned in the 5.03 (Service Unavailable) response, the
with a new mitigation request (i.e., a new 'mid') that repeats all DOTS client retries with a new mitigation request (i.e., a new
the parameters as sent in the failed mitigation request (i.e., the 'mid') that repeats all the parameters as sent in the failed
one including the ACL attributes).</t> mitigation request (i.e., the one including the ACL attributes).</t>
<t>If, during an active mitigation, the 'activation-type' is changed <t>If, during an active mitigation, the 'activation-type' is changed
at the DOTS server (e.g., as a result of an external action) for an at the DOTS server (e.g., as a result of an external action) for an
ACL bound to a DOTS client, the DOTS server notifies that DOTS ACL bound to a DOTS client, the DOTS server notifies that DOTS
client of the change by including the corresponding ACL parameters client of the change by including the corresponding ACL parameters
in an asynchronous notification (the DOTS client is observing the in an asynchronous notification (the DOTS client is observing the
active mitigation) or in a response to a polling request (Section active mitigation) or in a response to a polling request (<xref
4.4.2.2 of <xref target="RFC8782"></xref>).</t> target="RFC9132" sectionFormat="of" section="4.4.2.2"/>).</t>
<t>If the DOTS signal and data channels of a DOTS client are not <t>If the DOTS signal and data channels of a DOTS client are not
established with the same DOTS server of a DOTS server domain, the established with the same DOTS server of a DOTS server domain, the
above request processing operations are undertaken using the above request processing operations are undertaken using the
coordination mechanism discussed in <xref target="bind"></xref>.</t> coordination mechanism discussed in <xref target="bind" format="defaul
t"/>.</t>
<t>This specification does not require any modification to the <t>This specification does not require any modification to the
efficacy update and the withdrawal procedures defined in <xref efficacy update and the withdrawal procedures defined in <xref target=
target="RFC8782"></xref>. In particular, ACL-related clauses are not "RFC9132" format="default"/>. In particular, ACL-related clauses are not
included in a PUT request used to send an efficacy update and DELETE included in a PUT request used to send an efficacy update and DELETE
requests.</t> requests.</t>
</section> </section>
<section anchor="YANG" numbered="true" toc="default">
<section anchor="YANG" title="DOTS Signal Filtering Control Module "> <name>DOTS Signal Filtering Control Module</name>
<section anchor="tree" title="Tree Structure"> <section anchor="tree" numbered="true" toc="default">
<name>Tree Structure</name>
<t>This document augments the "ietf-dots-signal-channel" YANG <t>This document augments the "ietf-dots-signal-channel" YANG
module defined in <xref target="RFC8782"></xref> for managing module defined in <xref target="RFC9132" format="default"/> for mana ging
filtering rules.</t> filtering rules.</t>
<t>This document defines the YANG module <t>This document defines the YANG module
"ietf-dots-signal-control", which has the following tree "ietf-dots-signal-control", which has the following tree
structure:<figure> structure:</t>
<artwork><![CDATA[module: ietf-dots-signal-control
augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw acl-list* [acl-name] {control-filtering}?
+--rw acl-name
| -> /ietf-data:dots-data/dots-client/acls/acl/name
+--rw activation-type? ietf-data:activation-type
]]></artwork> <sourcecode type="yangtree">
</figure></t> module: ietf-dots-signal-control
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- acl-list* [acl-name]
+-- acl-name
| -> /data-channel:dots-data/dots-client/acls/acl/name
+-- activation-type? data-channel:activation-type
</sourcecode >
</section> </section>
<section numbered="true" toc="default">
<section title="YANG Module"> <name>YANG Module</name>
<t>This YANG module is not intended to be used via <t>This YANG module is not intended to be used via
NETCONF/RESTCONF for DOTS server management purposes; such module NETCONF/RESTCONF for DOTS server management purposes; such a module
is out of the scope of this document. It serves only to provide a is out of the scope of this document. It serves only to provide a
data model and encoding, but not a management data model.</t> data model and encoding, but not a management data model.</t>
<t>This module uses types defined in <xref target="RFC8783" format=" default"/>.</t>
<t>This module uses types defined in <xref <sourcecode name="ietf-dots-signal-control@2021-09-01.yang" type="yang" markers
target="RFC8783"></xref>.</t> ="true"><![CDATA[
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-signal-control@2
019-05-13.yang"
module ietf-dots-signal-control { module ietf-dots-signal-control {
yang-version 1.1; yang-version 1.1;
namespace namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
"urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
prefix dots-control; prefix dots-control;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix ietf-signal; prefix dots-signal;
reference reference
"RFC 8782: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix data-channel;
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Kaname Nishizuka Author: Kaname Nishizuka
<mailto:kaname@nttv6.jp> <mailto:kaname@nttv6.jp>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Konda, Tirumaleswar Reddy Author: Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:kondtir@gmail.com>
Author: Takahiko Nagata Author: Takahiko Nagata
<mailto:nagata@lepidum.co.jp>"; <mailto:nagata@lepidum.co.jp>";
description description
"This module contains YANG definition for the signaling "This module contains YANG definition for the signaling
messages exchanged between a DOTS client and a DOTS server messages exchanged between a DOTS client and a DOTS server
to control, by means of the DOTS signal channel, filtering to control, by means of the DOTS signal channel, filtering
rules configured using the DOTS data channel. rules configured using the DOTS data channel.
Copyright (c) 2020 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). (https://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 9133; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-05-13 { revision 2021-09-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Controlling Filtering Rules Using Distributed "RFC 9133: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS) Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel"; Signal Channel";
} }
feature control-filtering { sx:augment-structure "/dots-signal:dots-signal"
description + "/dots-signal:message-type"
"This feature means that the DOTS signal channel is able + "/dots-signal:mitigation-scope"
to manage the filtering rules created by the same DOTS + "/dots-signal:scope" {
client using the DOTS data channel.";
}
augment "/ietf-signal:dots-signal/ietf-signal:message-type"
+ "/ietf-signal:mitigation-scope/ietf-signal:scope" {
if-feature control-filtering;
description "ACL name and activation type."; description
"ACL name and activation type.";
list acl-list { list acl-list {
key "acl-name"; key "acl-name";
description description
"List of ACLs as defined using the DOTS data "List of ACLs as defined using the DOTS data
channel. ACLs bound to a DOTS client are uniquely channel. ACLs bound to a DOTS client are uniquely
identified by a name."; identified by a name.";
leaf acl-name { leaf acl-name {
type leafref { type leafref {
path "/ietf-data:dots-data/ietf-data:dots-client" path "/data-channel:dots-data/data-channel:dots-client"
+ "/ietf-data:acls/ietf-data:acl/ietf-data:name"; + "/data-channel:acls/data-channel:acl"
+ "/data-channel:name";
}
description
"Reference to the ACL name bound to a DOTS client.";
} }
description leaf activation-type {
"Reference to the ACL name bound to a DOTS client."; type data-channel:activation-type;
} default "activate-when-mitigating";
leaf activation-type { description
type ietf-data:activation-type; "Sets the activation type of an ACL.";
default "activate-when-mitigating";
description
"Sets the activation type of an ACL.";
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sample" numbered="true" toc="default">
<section anchor="sample" title="Some Examples"> <name>Some Examples</name>
<t>This section provides some examples to illustrate the behavior <t>This section provides some examples to illustrate the behavior
specified in <xref target="filtering"></xref>. These examples are specified in <xref target="filtering" format="default"/>. These examples a re
provided for illustration purposes; they should not be considered as provided for illustration purposes; they should not be considered as
deployment recommendations.</t> deployment recommendations.</t>
<section anchor="sample1" numbered="true" toc="default">
<section anchor="sample1" title="Conflict Handling"> <name>Conflict Handling</name>
<t>Let's consider a DOTS client which contacts its DOTS server during <t>Let's consider a DOTS client that contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued 'idle' time to install an accept-list allowing for UDP traffic issued
from 2001:db8:1234::/48 with a destination port number 443 to be from 2001:db8:1234::/48 with a destination port number 443 to be
forwarded to 2001:db8:6401::2/127. It does so by sending, for example, forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
a PUT request shown in <xref target="PUT"></xref>.</t> a PUT request as shown in <xref target="PUT" format="default"/>.</t>
<figure anchor="PUT">
<t><figure anchor="PUT" <name>DOTS Data Channel Request to Create a Filter</name>
title="DOTS Data Channel Request to Create a Filter"> <sourcecode>
<artwork align="left"><![CDATA[PUT /restconf/data/ietf-dots-data-cha PUT /restconf/data/ietf-dots-data-channel:dots-data\
nnel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=an-accept-list HTTP/1.1 /acl=an-accept-list HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "an-accept-list", "name": "an-accept-list",
skipping to change at line 682 skipping to change at line 644
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> </sourcecode>
</figure>
<t>Sometime later, consider that a DDoS attack is detected by the DOTS <t>Sometime later, consider that a DDoS attack is detected by the DOTS
client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a
mitigation request to its DOTS server as shown in <xref mitigation request to its DOTS server as shown in <xref target="mitigate
target="mitigate"></xref>.</t> " format="default"/>.</t>
<figure anchor="mitigate">
<t><figure anchor="mitigate" <name>DOTS Signal Channel Mitigation Request</name>
title="DOTS Signal Channel Mitigation Request"> <sourcecode>
<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=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
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": {
"scope": [ "scope": [
skipping to change at line 715 skipping to change at line 676
"2001:db8:6401::2/127" "2001:db8:6401::2/127"
], ],
"target-protocol": [ "target-protocol": [
17 17
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>The DOTS server immediately accepts the request by replying with
<t>The DOTS server accepts immediately the request by replying with 2.01 (Created) (<xref target="response" format="default"/> depicts the m
2.01 (Created) (<xref target="response"></xref> depicts the message essage
body of the response).</t> body of the response).</t>
<figure anchor="response">
<t><figure anchor="response" title="Status Response (Message Body)"> <name>Status Response (Message Body)</name>
<artwork align="left"><![CDATA[{ <sourcecode>
{
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 123, "mid": 123,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>Assuming the DOTS client subscribed to asynchronous notifications, <t>Assuming the DOTS client subscribed to asynchronous notifications,
when the DOTS server concludes that some of the attack sources belong when the DOTS server concludes that some of the attack sources belong
to 2001:db8:1234::/48, it sends a notification message with 'status' to 2001:db8:1234::/48, it sends a notification message with 'status'
code set to '1 (Attack mitigation is in progress)' and code set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set
'conflict-cause' set to '2' (conflict-with-acceptlist) to the DOTS to 2 (conflict-with-acceptlist) to the DOTS client to indicate that
client to indicate that this mitigation request is in progress, but a this mitigation request is in progress, but a conflict is
conflict is detected.</t> detected.</t>
<t>Upon receipt of the notification message from the DOTS server, the <t>Upon receipt of the notification message from the DOTS server, the
DOTS client sends a PUT request to deactivate the "an-accept-list" ACL DOTS client sends a PUT request to deactivate the "an-accept-list" ACL
as shown in <xref target="control"></xref>.</t> as shown in <xref target="control" format="default"/>.</t>
<t>The DOTS client can also decide to send a PUT request to deactivate <t>The DOTS client can also decide to send a PUT request to deactivate
the "an-accept-list" ACL, if suspect traffic is received from an the "an-accept-list" ACL if suspect traffic is received from an
accept-listed source (2001:db8:1234::/48). The structure of that PUT accept-listed source (2001:db8:1234::/48). The structure of that PUT
is the same as the one shown in <xref target="control"></xref>.</t> is the same as the one shown in <xref target="control" format="default"/
>.</t>
<t><figure anchor="control" <figure anchor="control">
title="PUT for Deactivating a Conflicting Filter"> <name>PUT for Deactivating a Conflicting Filter</name>
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <sourcecode>
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=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=124" Uri-Path: "mid=124"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at line 784 skipping to change at line 742
{ {
"acl-name": "an-accept-list", "acl-name": "an-accept-list",
"activation-type": "deactivate" "activation-type": "deactivate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>Then, the DOTS server deactivates the "an-accept-list" ACL and replie
<t>Then, the DOTS server deactivates "an-accept-list" ACL and replies s
with 2.04 (Changed) response to the DOTS client to confirm the with a 2.04 (Changed) response to the DOTS client to confirm the
successful operation. The message body is similar to the one depicted successful operation. The message body is similar to the one depicted
in <xref target="response"></xref>.</t> in <xref target="response" format="default"/>.</t>
<t>Once the attack is mitigated, the DOTS client may use the data <t>Once the attack is mitigated, the DOTS client may use the data
channel to retrieve its ACLs maintained by the DOTS server. As shown channel to retrieve its ACLs maintained by the DOTS server. As shown
in <xref target="GET-2"></xref>, the activation type is set to in <xref target="GET-2" format="default"/>, the activation type is set t
'deactivate' as set by the DOTS signal channel (<xref o
target="control"></xref>) instead of the type initially set using the 'deactivate' as set by the DOTS signal channel (<xref target="control" f
DOTS data channel (<xref target="PUT"></xref>).</t> ormat="default"/>) instead of the type initially set using the
DOTS data channel (<xref target="PUT" format="default"/>).</t>
<t><figure anchor="GET-2" <figure anchor="GET-2">
title="DOTS Data Channel GET Response after Mitigation (Message Body <name>DOTS Data Channel GET Response after Mitigation (Message Body)</
)"> name>
<artwork align="left"><![CDATA[{ <sourcecode>
{
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "an-accept-list", "name": "an-accept-list",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "deactivate", "activation-type": "deactivate",
"pending-lifetime": 10021, "pending-lifetime": 10021,
"aces": { "aces": {
"ace": [ "ace": [
{ {
skipping to change at line 834 skipping to change at line 789
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> </sourcecode>
</figure>
</section> </section>
<section anchor="sample2" numbered="true" toc="default">
<section anchor="sample2" <name>On-Demand Activation of an Accept-List Filter</name>
title="On-Demand Activation of an Accept-List Filter"> <t>Let's consider a DOTS client that contacts its DOTS server during
<t>Let's consider a DOTS client which contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued 'idle' time to install an accept-list allowing for UDP traffic issued
from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It
does so by sending, for example, a PUT request shown in <xref does so by sending, for example, a PUT request shown in <xref
target="PUT1"></xref>. The DOTS server installs this filter with a target="PUT1" format="default"/>. The DOTS server installs this filter
"deactivated" state.</t> with a "deactivated" state.</t>
<figure anchor="PUT1">
<t><figure anchor="PUT1" <name>DOTS Data Channel Request to Create an Accept-List Filter</name>
title="DOTS Data Channel Request to Create an Accept-List Filter"> <sourcecode>
<artwork align="left"><![CDATA[PUT /restconf/data/ietf-dots-data-cha PUT /restconf/data/ietf-dots-data-channel:dots-data\
nnel:dots-data\
/dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
/acl=my-accept-list HTTP/1.1 /acl=my-accept-list HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "my-accept-list", "name": "my-accept-list",
skipping to change at line 882 skipping to change at line 837
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> </sourcecode>
</figure>
<t>Sometime later, consider that a UDP DDoS attack is detected by the <t>Sometime later, consider that a UDP DDoS attack is detected by the
DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let
the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS
client domain. Consequently, the DOTS client sends a mitigation client domain. Consequently, the DOTS client sends a mitigation
request to its DOTS server as shown in <xref request to its DOTS server as shown in <xref target="mitigate1" format="
target="mitigate1"></xref>.</t> default"/>.</t>
<figure anchor="mitigate1">
<t><figure anchor="mitigate1" <name>DOTS Signal Channel Mitigation Request with a Filter Control</na
title="DOTS Signal Channel Mitigation Request with a Filter Control" me>
> <sourcecode>
<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=ioiuLoZqo4SLv64TLPXrxA" Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
Uri-Path: "mid=4879" Uri-Path: "mid=4879"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at line 923 skipping to change at line 877
{ {
"acl-name": "my-accept-list", "acl-name": "my-accept-list",
"activation-type": "immediate" "activation-type": "immediate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>The DOTS server activates the "my-accept-list" ACL and replies with
<t>The DOTS server activates "my-accept-list" ACL and replies with a 2.01 (Created) response to the DOTS client to confirm the successful
2.01 (Created) response to the DOTS client to confirm the successful
operation.</t> operation.</t>
</section> </section>
<section anchor="sample3" <section anchor="sample3" numbered="true" toc="default">
title="DOTS Servers/Mitigators Lacking Capacity"> <name>DOTS Servers/Mitigators Lacking Capacity</name>
<t>This section describes a scenario in which a DOTS client activates <t>This section describes a scenario in which a DOTS client activates
a drop-list or a rate-limit filter during an attack.</t> a drop-list or a rate-limit filter during an attack.</t>
<t>Consider a DOTS client that contacts its DOTS server during 'idle' <t>Consider a DOTS client that contacts its DOTS server during 'idle'
time to install an accept-list that rate-limits all (or a part time to install an accept-list that rate-limits all (or a part
thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
countermeasure whenever required. Installing the accept-list can be countermeasure whenever required. Installing the accept-list can be
done by sending, for example, the PUT request shown in <xref done by sending, for example, the PUT request shown in <xref
target="rate"></xref>. The DOTS server installs this filter with a target="rate" format="default"/>. The DOTS server installs this filter
"deactivated" state.</t> with a "deactivated" state.</t>
<figure anchor="rate">
<t><figure anchor="rate" <name>DOTS Data Channel Request to Create a Rate-Limit Filter</name>
title="DOTS Data Channel Request to Create a Rate-Limit Filter"> <sourcecode>
<artwork><![CDATA[PUT /restconf/data/ietf-dots-data-channel:dots-dat PUT /restconf/data/ietf-dots-data-channel:dots-data\
a\
/dots-client=OopPisZqo4SLv64TLPXrxA/acls\ /dots-client=OopPisZqo4SLv64TLPXrxA/acls\
/acl=my-ratelimit-list HTTP/1.1 /acl=my-ratelimit-list HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "my-ratelimit-list", "name": "my-ratelimit-list",
skipping to change at line 979 skipping to change at line 931
"forwarding": "accept", "forwarding": "accept",
"rate-limit": "20000.00" "rate-limit": "20000.00"
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>Consider now that a DDoS attack is detected by the DOTS client on <t>Consider now that a DDoS attack is detected by the DOTS client on
2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
request to its DOTS server (<xref target="ratel"></xref>).</t> request to its DOTS server (<xref target="ratel" format="default"/>).</t
>
<t><figure anchor="ratel" <figure anchor="ratel">
title="DOTS Signal Channel Mitigation Request"> <name>DOTS Signal Channel Mitigation Request</name>
<artwork><![CDATA[Header: PUT (Code=0.03) <sourcecode>
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=OopPisZqo4SLv64TLPXrxA" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=85" Uri-Path: "mid=85"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"2001:db8:123::/48" "2001:db8:123::/48"
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>For some reason (e.g., the DOTS server, or the mitigator, is <t>For some reason (e.g., the DOTS server, or the mitigator, is
lacking a capability or capacity), the DOTS client is still receiving lacking a capability or capacity), the DOTS client is still receiving
attack traffic which saturates available links. To soften the problem, attack traffic, which saturates available links. To soften the
the DOTS client decides to activate the filter that rate-limits the problem, the DOTS client decides to activate the filter that
traffic destined to the DOTS client domain. To that aim, the DOTS rate-limits the traffic destined to the DOTS client domain. To that
client sends the mitigation request to its DOTS server shown in <xref aim, the DOTS client sends the mitigation request to its DOTS server
target="rateres"></xref>.</t> shown in <xref target="rateres" format="default"/>.</t>
<figure anchor="rateres">
<t><figure anchor="rateres" <name>DOTS Signal Channel Mitigation Request to Activate a Rate-Limit
title="DOTS Signal Channel Mitigation Request to Activate a Rate-Lim Filter</name>
it Filter"> <sourcecode>
<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: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=86" Uri-Path: "mid=86"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at line 1047 skipping to change at line 997
{ {
"acl-name": "my-ratelimit-list", "acl-name": "my-ratelimit-list",
"activation-type": "immediate" "activation-type": "immediate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
<t>Then, the DOTS server activates the "my-ratelimit-list" ACL and repli
<t>Then, the DOTS server activates "my-ratelimit-list" ACL and replies es
with 2.04 (Changed) response to the DOTS client to confirm the with a 2.04 (Changed) response to the DOTS client to confirm the
successful operation.</t> successful operation.</t>
<t>As the attack mitigation evolves, the DOTS client may decide to <t>As the attack mitigation evolves, the DOTS client may decide to
deactivate the rate-limit policy (e.g., upon receipt of notification deactivate the rate-limit policy (e.g., upon receipt of a notification
status change from 'attack-exceeded-capability' to status change from 'attack-exceeded-capability' to
'attack-mitigation-in-progress'). Based on the mitigation status 'attack-mitigation-in-progress'). Based on the mitigation status
conveyed by the DOTS server, the DOTS client can de-activate the conveyed by the DOTS server, the DOTS client can deactivate the
rate-limit action. It does so by sending the request shown in <xref rate-limit action. It does so by sending the request shown in <xref targ
target="rateres2"></xref>.</t> et="rateres2" format="default"/>.</t>
<figure anchor="rateres2">
<t><figure anchor="rateres2" <name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limi
title="DOTS Signal Channel Mitigation Request to Deactivate a Rate-L t Filter</name>
imit Filter"> <sourcecode type="cbor">
<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: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=87" Uri-Path: "mid=87"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at line 1090 skipping to change at line 1037
{ {
"acl-name": "my-ratelimit-list", "acl-name": "my-ratelimit-list",
"activation-type": "deactivate" "activation-type": "deactivate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
]]></artwork> </sourcecode>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="map" title="DOTS Signal Channel CBOR Mappings Registry"> <section anchor="map" numbered="true" toc="default">
<t>This specification registers the following parameters in the IANA <name>DOTS Signal Channel CBOR Key Values Subregistry</name>
"DOTS Signal Channel CBOR Key Values" registry <xref <t>Per this specification, IANA has registered the following parameters
target="Key-Map"></xref>.</t> in the
"DOTS Signal Channel CBOR Key Values" subregistry within the
"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel" registry <xref target="Key-Map" format="default"/>.</t>
<t><list style="symbols"> <table anchor="table2">
<t>Note to the RFC Editor: Please delete (TBA1-TBA2) once the CBOR
keys are assigned from the 1-16383 range. Please update Table 1
accordingly.</t>
</list></t>
<t><figure align="center"> <thead>
<artwork><![CDATA[ +--------------------+--------+-------+-------- <tr>
----+---------------+ <th>Parameter Name</th>
| Parameter Name | CBOR | CBOR | Change | Specification | <th>CBOR Key Value</th>
| | Key | Major | Controller | Document(s) | <th>CBOR Major Type</th>
| | Value | Type | | | <th>Change Controller</th>
+====================+========+=======+============+===============+ <th>Specification Document(s)</th>
| activation-type | 52 | | | | </tr>
| | (TBA1) | 0 | IESG | [RFCXXXX] | </thead>
+--------------------+--------+-------+------------+---------------+ <tbody>
| ietf-dots-signal- | 53 | | | | <tr>
| control:acl-list | (TBA2) | 4 | IESG | [RFCXXXX] | <td>activation-type</td>
+--------------------+--------+-------+------------+---------------+ <td>52</td>
]]></artwork> <td>0</td>
</figure></t> <td>IESG</td>
</section> <td>RFC 9133</td>
</tr>
<tr>
<td>ietf-dots-signal-control:acl-list</td>
<td>53</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9133</td>
</tr>
<section anchor="yang-iana" </tbody>
title="DOTS Signal Filtering Control YANG Module"> </table>
<t>This document requests IANA to register the following URI in the
"ns" subregistry within the "IETF XML Registry" <xref
target="RFC3688"></xref>:</t>
<t><figure> </section>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-signa <section anchor="yang-iana" numbered="true" toc="default">
l-control <name>A New YANG Module</name>
Registrant Contact: The IESG. <t>IANA has registered the following URI in the
XML: N/A; the requested URI is an XML namespace. "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
ormat="default"/>:</t>
]]></artwork> <dl newline="false" spacing="compact">
</figure></t> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
<dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>This document requests IANA to register the following YANG module <t>IANA has registered the following YANG module
in the "YANG Module Names" subregistry <xref target="RFC7950"></xref> in the "YANG Module Names" subregistry <xref target="RFC6020" format="de
fault"/>
within the "YANG Parameters" registry.</t> within the "YANG Parameters" registry.</t>
<t><figure> <dl newline="false" spacing="compact">
<artwork><![CDATA[ Name: ietf-dots-signal-control <dt>Name:</dt><dd>ietf-dots-signal-control</dd>
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
Maintained by IANA: N <dt>Maintained by IANA:</dt><dd>N</dd>
Prefix: dots-control <dt>Prefix:</dt><dd>dots-control</dd>
Reference: RFC XXXX <dt>Reference:</dt><dd>RFC 9133</dd>
</dl>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="security" title="Security Considerations">
<t>The security considerations for the DOTS signal channel protocol are <t>The security considerations for the DOTS signal channel protocol are
discussed in Section 10 of <xref target="RFC8782"></xref>, while those discussed in <xref target="RFC9132" sectionFormat="of" section="11"/>,
for the DOTS data channel protocol are discussed in Section 10 of <xref while those for the DOTS data channel protocol are discussed in <xref
target="RFC8783"></xref>. The following discusses the security target="RFC8783" sectionFormat="of" section="10"/>. The following
considerations that are specific to the DOTS signal channel extension discusses the security considerations that are specific to the DOTS
defined in this document.</t> signal channel extension defined in this document.</t>
<t>This specification does not allow the creation of new filtering rules,
<t>This specification does not allow to create new filtering rules,
which is the responsibility of the DOTS data channel. DOTS client which is the responsibility of the DOTS data channel. DOTS client
domains should be adequately prepared prior to an attack, e.g., by domains should be adequately prepared prior to an attack, e.g., by
creating filters that will be activated on demand when an attack is creating filters that will be activated on demand when an attack is
detected.</t> detected.</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 can not tweak filtering rules created by other particular, a DOTS client can not tweak filtering rules created by other
DOTS clients of the same DOTS client domain. As a reminder, DOTS servers DOTS clients of the same DOTS client domain. As a reminder, DOTS servers
must associate filtering rules with the DOTS client that created these must associate filtering rules with the DOTS client that created these
resources. Failure to ensure such association by a DOTS server will have resources. Failure to ensure such association by a DOTS server will have
severe impact on DOTS client domains.</t> severe impact on DOTS client domains.</t>
<t>A compromised DOTS client can use the filtering control capability to <t>A compromised DOTS client can use the filtering control capability to
exacerbate an ongoing attack. Likewise, such a compromised DOTS client exacerbate an ongoing attack. Likewise, such a compromised DOTS client
may abstain from reacting to an ACL conflict notification received from may abstain from reacting to an ACL conflict notification received from
the DOTS server during attacks. These are not new attack vectors, but the DOTS server during attacks. These are not new attack vectors, but
variations of threats discussed in <xref target="RFC8782"></xref> and variations of threats discussed in <xref target="RFC9132"
<xref target="RFC8783"></xref>. DOTS operators should carefully monitor format="default"/> and <xref target="RFC8783" format="default"/>. DOTS
and audit DOTS agents to detect misbehaviors and to deter misuses.</t> operators should carefully monitor and audit DOTS agents to detect
misbehaviors and deter misuses.</t>
</section> </section>
<section anchor="ack" title="Acknowledgements">
<t>Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer
Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw, Erik
Kline, and Eric Vyncke for the comments.</t>
<t>Thanks to Benjamin Kaduk for the AD review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7950"?>
<?rfc include="reference.RFC.3688"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include="reference.RFC.8782"?>
<?rfc include="reference.RFC.8783" ?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.8612"?>
<?rfc include='reference.RFC.7951'?>
<?rfc include='reference.RFC.8340'?>
<?rfc include='reference.I-D.ietf-dots-architecture'?>
<reference anchor="Interop"
target="https://datatracker.ietf.org/meeting/103/materials/slid
es-103-dots-interop-report-from-ietf-103-hackathon-00">
<front>
<title>DOTS Interop test report, IETF 103 Hackathon</title>
<author fullname="Kaname Nishizuka" initials="K."
surname="Nishizuka">
<organization>NTT Communications</organization>
<address>
<postal>
<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<region></region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>kaname@nttv6.jp</email>
</address>
</author>
<author fullname="Jon Shallow" initials="J." surname=" Shallow">
<organization>J.NCC Group</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country> <references>
</postal> <name>References</name>
<references>
<phone></phone> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<facsimile></facsimile> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<email></email> FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<uri></uri> FC.3688.xml"/>
</address> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="Liang Xia" initials="L." surname="Xia "> FC.8174.xml"/>
<organization>Huawei</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8791.xml"/>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country> <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132">
</postal>
<phone></phone> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification</title>
<facsimile></facsimile> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" rol
e="editor">
<organization />
</author>
<author initials="J" surname="Shallow" fullname="Jon Shallow">
<organization />
</author>
<author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
<organization />
</author>
<email></email> <date month="September" year="2021" />
</front>
<seriesInfo name="RFC" value="9132" />
<seriesInfo name="DOI" value="10.17487/RFC9132"/>
<uri></uri> </reference>
</address>
</author>
<date month="November" year="2018" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8783.xml"/>
</reference> </references>
<references>
<name>Informative References</name>
<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.7951.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.8811.xml"/>
<reference anchor="Key-Map" <reference anchor="INTEROP" target="https://datatracker.ietf.org/meeting
target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s /103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00">
ignal-channel-cbor-key-values"> <front>
<front> <title>DOTS Interop test report, IETF 103 Hackathon</title>
<title>DOTS Signal Channel CBOR Key Values</title> <author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka
">
<organization>NTT Communications</organization>
<address>
<postal>
<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<region/>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>kaname@nttv6.jp</email>
</address>
</author>
<author fullname="Jon Shallow" initials="J." surname=" Shallow">
<organization>J.NCC Group</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email/>
<uri/>
</address>
</author>
<author fullname="Liang Xia" initials="L." surname="Xia ">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email/>
<uri/>
</address>
</author>
<date month="November" year="2018"/>
</front>
</reference>
<author fullname="IANA"> <reference anchor="Key-Map" target="https://www.iana.org/assignments/dot
<organization></organization> s">
</author> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel</title>
<author fullname="IANA">
<organization/>
</author>
</front>
</reference>
</references>
<date />
</front>
</reference>
</references> </references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Wei Pan"/>, <contact fullname="Xia
Liang"/>, <contact fullname="Jon Shallow"/>, <contact fullname="Dan
Wing"/>, <contact fullname="Christer
Holmberg"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Tim
Chown"/>, <contact fullname="Murray Kucherawy"/>, <contact
fullname="Roman Danyliw"/>, <contact fullname="Erik
Kline"/>, and <contact fullname="Éric Vyncke"/> for the comments.</t>
<t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 181 change blocks. 
658 lines changed or deleted 642 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/