<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     consensus="true" number="8909" docName="draft-ietf-dots-signal-filter-control-07"
     ipr="trust200902">
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
     sortRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 2.46.0 -->

  <front>
    <title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules
    Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
    Channel</title>
    <seriesInfo name="RFC" value="8909"/>

<!-- [rfced] *AD, we note that the Security Considerations section of this
document does not contain the text at
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. Please
review and let us know if this is acceptable or if updates are needed.
-->

 <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>
          <region>Tokyo</region>
          <country>Japan</country>
        </postal>
        <email>kaname@nttv6.jp</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <region/>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

<!-- [rfced] This question is for author Tirumaleswar Reddy. In RFCs 8768,
8782, and 8783, we see that your name appears as "T. Reddy.K" in the
document header and as "Tirumaleswar Reddy.K" in the Authors' Addresses
section. Would you like to use the same form for your name in this
document? Note that your name appears in three locations in the output
files for document: document header, Authors' Addresses, and the YANG
module.

Current
Document header:
   T. Reddy

Authors' Addresses:
   Tirumaleswar Reddy

YANG Module:
   Konda, Tirumaleswar Reddy

Perhaps
Document header:
   T. Reddy.K

Authors' Addresses:
   Tirumaleswar Reddy.K

YANG Module:
   Tirumaleswar Reddy.K
-->

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="McAfee">McAfee, Inc.</organization>
      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>
          <city>Bangalore</city>

          <region>Karnataka</region>
          <code>560071</code>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>

    <author fullname="Takahiko Nagata" initials="T." surname="Nagata">
      <organization>Lepidum</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Japan</country>
        </postal>
        <email>nagata@lepidum.co.jp</email>
      </address>
    </author>
    <date /> month="September" year="2020"/>
    <workgroup>DOTS</workgroup>
    <keyword>Mitigation</keyword>
    <keyword>Automation</keyword>
    <keyword>Filtering</keyword>
    <keyword>Protective Networking</keyword>
    <keyword>Protected Networks</keyword>
    <keyword>Security</keyword>
    <keyword>Anti-DDoS</keyword>
    <keyword>Reactive</keyword>
    <keyword>Collaborative Networking</keyword>
    <keyword>Collaborative Security</keyword>
    <abstract>
      <t>This document specifies an extension to the Distributed
      Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol
      so that DOTS clients can control their filtering rules when an attack
      mitigation is active.</t>
      <t>Particularly, this extension allows a DOTS client to activate or
      de-activate
      deactivate existing filtering rules during a DDoS Distributed
      Denial-of-Service (DDoS) attack. The
      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
      data channel protocol.</t>
    </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>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <section anchor="problem" title="The Problem"> numbered="true" toc="default">
        <name>The Problem</name>
        <t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
        architecture <xref target="I-D.ietf-dots-architecture"></xref>, target="I-D.ietf-dots-architecture" format="default"/>, DOTS
        clients and servers communicate using both a signal channel protocol
        <xref target="RFC8782"></xref> target="RFC8782" format="default"/> and a data channel protocol <xref
        target="RFC8783"></xref>.</t> target="RFC8783" format="default"/>.</t>

<!-- [rfced] Will readers understand what "its" refers to here? Would the
suggested text below improve readability?

Original:
   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.

Perhaps:
   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.
-->

        <t>The DOTS data channel protocol <xref target="RFC8783"></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 is one of its tasks
	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> target="RFC8782" format="default"/> is
        designed to be resilient under extremely hostile network conditions
        and provides continued contact between DOTS agents even as DDoS attack
        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
        DOTS client may send mitigation requests (as per Section 4.4 of <xref
        target="RFC8782"></xref>)
	target="RFC8782" sectionFormat="of" section="4.4"/>) to a DOTS server over the active signal
        channel. While mitigation is active, the DOTS server periodically
        sends status messages to the DOTS client, including basic mitigation
        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
        to the DOTS client will likely be dropped. However, the DOTS server
        may still receive DOTS messages sent from the DOTS client over the
        signalling
        signaling channel thanks to the heartbeat requests keeping the
        channel active (as described in Section 4.7 of <xref
        target="RFC8782"></xref>).</t> target="RFC8782"
	sectionFormat="of" section="4.7"/>).</t>
        <t>Unlike the DOTS signal channel protocol, the DOTS data channel
        protocol is not expected to deal with attack conditions. As such, an
        issue that might be encountered in some deployments is when filters
        installed by means of the DOTS data channel protocol may not function
        as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
        attack. In such conditions conditions, the DOTS data channel protocol cannot be
        used to change these filters, which may complicate DDoS mitigation
        operations <xref target="Interop"></xref>.</t> target="INTEROP" format="default"/>.</t>
        <t>A typical case is a conflict between filtering rules installed by a
        DOTS client and the mitigation actions of a DDoS mitigator. Consider,
        for instance, a DOTS client that configures during 'idle' time (i.e.,
        no mitigation is active) some filtering rules using the DOTS data
        channel protocol to permit traffic from accept-listed sources.
        However, during a volumetric DDoS attack attack, the DDoS mitigator identifies
        the source addresses/prefixes in the accept-listed filtering rules are
        attacking the target. For example, an attacker can spoof the IP
        addresses of accept-listed sources to generate attack traffic traffic, or the
        attacker can compromise the accept-listed sources and program them to
        launch a DDoS attack.</t>

        <t><xref target="RFC8782"></xref> is designed so

<!-- [rfced] We note that Sections 9.6.2 and 9.6.4 of RFC 8782 define the DDoS server
        notifies
status and conflict-cause codes. In the above conflict to sentences below, sometimes the DOTS client (that is,
        'conflict-cause' parameter set to 2 (Conflicts with an existing accept
        list)), "Label" from
these sections is used and sometimes the "Definition" is used. For
example, in the first sentence below, "Attack mitigation is in progress"
is the Description but "attack-mitigation-in-progress" is the Label. Should
this be consistent?

Original:
   Assuming the DOTS client may not be able subscribed to withdraw the
        accept-list rules during asynchronous notifications,
   when the attack DOTS server concludes that some of the attack sources belong
   to 2001:db8:1234::/48, it sends a notification message with 'status'
   code set to '1 (Attack mitigation is in progress)' and 'conflict-
   cause' set to '2' (conflict-with-acceptlist) to the DOTS client to
   indicate that this mitigation request is in progress, but a conflict
   is detected.
   ...
   As the attack mitigation evolves, the DOTS client may decide to
   deactivate the rate-limit policy (e.g., upon receipt of notification
   status change from 'attack-exceeded-capability' to 'attack-
   mitigation-in-progress').
   ...
   [RFC8782] is designed so that the DDoS server notifies the above
   conflict to the DOTS client (that is, 'conflict-cause' parameter set
   to 2 (Conflicts with an existing accept list)), but the DOTS client
   may not be able to withdraw the accept-list rules during the attack
   period due to the high-volume attack traffic saturating the inbound
   link to the DOTS client domain.

Perhaps (using Label consistently):
   Assuming the DOTS client subscribed to asynchronous notifications,
   when the DOTS server concludes that some of the attack sources belong
   to 2001:db8:1234::/48, it sends a notification message with 'status'
   code set to 1 (attack-mitigation-in-progress) and 'conflict-
   cause' set to 2 (conflict-with-acceptlist) to the DOTS client to
   indicate that this mitigation request is in progress, but a conflict
   is detected.
   ...
   As the attack mitigation evolves, the DOTS client may decide to
   deactivate the rate-limit policy (e.g., upon receipt of a notification
   status change from 'attack-exceeded-capability' to 'attack-
   mitigation-in-progress').
   ...
   [RFC8782] is designed so that the DDoS server notifies the above
   conflict to the DOTS client (that is, the 'conflict-cause' parameter set
   to 2 (conflict-with-acceptlist)), but the DOTS client
   may not be able to withdraw the accept-list rules during the attack
   period due to the high-volume attack traffic saturating the inbound
   link to the DOTS client domain.
-->

        <t><xref target="RFC8782" format="default"/> is designed so that the
        DDoS server notifies the above conflict to the DOTS client (that is, the
        'conflict-cause' parameter set to 2 (Conflicts with an existing
        accept-list)), but the DOTS client may not be able to withdraw the
        accept-list rules during the attack period due to the high-volume
        attack traffic saturating the inbound link to the DOTS client domain.
        In other words, the DOTS client cannot use the DOTS data channel
        protocol to withdraw the accept-list filters when a DDoS attack is in
        progress.</t>

      </section>
      <section anchor="sol"
               title="Controlling numbered="true" toc="default">
        <name>Controlling Filtering Rules Using DOTS Signal Channel"> Channel</name>
        <t>This specification addresses the problems discussed in <xref
        target="problem"></xref> target="problem" format="default"/> by adding a capability for managing filtering
        rules using the DOTS signal channel protocol, which enables a DOTS
        client to request the activation (or deactivation) of filtering rules
        during a DDoS attack. Note that creating these filtering rules is
        still the responsibility of the DOTS data channel <xref
        target="RFC8783"></xref>.</t> target="RFC8783" format="default"/>.</t>
        <t>The DOTS signal channel protocol is designed to enable a DOTS
        client to contact a DOTS server for help even under severe network
        congestion conditions. Therefore, extending the DOTS signal channel
        protocol to manage the filtering rules during an attack will enhance
        the protection capability offered by DOTS protocols.</t>

        <t><list style="empty">

<aside>
          <t>Note: The experiment at the IETF103 IETF 103 hackathon <xref
            target="Interop"></xref>
          target="INTEROP" format="default"/> showed that even when the
          inbound link is saturated by DDoS attack traffic, the DOTS client
          can signal mitigation requests using the DOTS signal channel over
          the saturated link.</t>
          </list></t>
</aside>
        <t>Conflicts that are induced by filters installed by other DOTS
        clients of the same domain are not discussed in this
        specification.</t>
        <t>An augmentation to the DOTS signal channel YANG module is defined
        in <xref target="YANG"></xref>.</t> target="YANG" format="default"/>.</t>
        <t>Sample examples are provided in <xref target="sample"></xref>, target="sample" format="default"/>, in
        particular: <list style="symbols">
            <t><xref target="sample1"></xref> </t>
        <ul spacing="normal">
          <li>
            <xref target="sample1" format="default"/> illustrates how the filter
            control extension is used when conflicts with Access Control Lists
            (ACLs) are detected and reported by a DOTS server.</t>

            <t><xref target="sample2"></xref> server.</li>
          <li>
            <xref target="sample2" format="default"/> shows how a DOTS client can
            instruct a DOTS server to safely forward some specific traffic in
            'attack' time.</t>

            <t><xref target="sample3"></xref> time.</li>
          <li>
            <xref target="sample3" format="default"/> shows how a DOTS client can
            react if the DDoS traffic is still being forwarded to the DOTS
            client domain even if mitigation requests were sent to a DOTS
            server.</t>
          </list></t>
            server.</li>
        </ul>
        <t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data
        <xref target="RFC7951"></xref> target="RFC7951" format="default"/> is used to illustrate the examples.</t>
      </section>
    </section>
    <section anchor="notation" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
      NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"
      format="default"/> <xref target="RFC8174"></xref> target="RFC8174" format="default"/> when, and
      only when, they appear in all capitals, as shown here.</t>
      <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
      target="RFC7950"></xref>. target="RFC7950" format="default"/>. The meaning of the symbols in the tree diagram
      is defined in <xref target="RFC8340"></xref>.</t> target="RFC8340" format="default"/>.</t>
    </section>
    <section title="Controlling numbered="true" toc="default">
      <name>Controlling Filtering Rules of a DOTS Client"> Client</name>
      <section anchor="bind" title="Binding numbered="true" toc="default">
        <name>Binding DOTS Data and Signal Channels"> Channels</name>
        <t>The filtering rules eventually managed using the DOTS signal
        channel protocol are created a priori by the same DOTS client using
        the DOTS data channel protocol. Managing conflicts with filters
        installed by other DOTS clients of the same domain is out of
        scope.</t>
        <t>As discussed in Section 4.4.1 of <xref target="RFC8782"></xref>, target="RFC8782" sectionFormat="of"
        section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the
        DOTS signal and data channels. This requirement is meant to facilitate
        binding DOTS channels used by the same DOTS client.</t>
        <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
        request, alias, and filtering rules are not restricted to the DOTS
        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
        requests, aliases, and filtering rules to coordinate their decisions
        for better mitigation operation efficiency. The exact details about
        such a mechanism is out of the scope of this document.</t>
        <t>A filtering rule controlled by the DOTS signal channel is
        identified by its ACL name (Section 4.3 of <xref
        target="RFC8782"></xref>). (<xref target="RFC8782"
	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
        used by distinct DOTS clients.</t>

        <t>The activation or deactivation of an ACL by the DOTS signal channel
        overrides the 'activation-type' (defined in Section 4.3 of <xref
        target="RFC8783"></xref>) target="RFC8783"
        sectionFormat="of" section="4.3"/>) a priori conveyed with the
        filtering rules using the DOTS data channel protocol.</t>
        <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
        value) of some of the filtering rules controlled by the DOTS signal
        channel or delete some of these filters. This behavior is deployment
        specific.</t>
      </section>
      <section title="DOTS numbered="true" toc="default">
        <name>DOTS Signal Channel Extension"> Extension</name>
        <section anchor="filtering" title="Parameters numbered="true" toc="default">
          <name>Parameters and Behaviors"> Behaviors</name>
          <t>This specification extends the mitigation request defined in
          Section 4.4.1 of
          <xref target="RFC8782"></xref> target="RFC8782" sectionFormat="of" section="4.4.1"/> to
          convey the intended control of configured filtering
          rules. Concretely, the DOTS client conveys the 'acl-list' attribute with
          the following sub-attributes in the CBOR Concise Binary Object
	  Representation (CBOR) body of a mitigation
          request (see the YANG structure in <xref target="tree"></xref>):<list style="hanging">
              <t hangText="acl-name:">A target="tree"
          format="default"/>):</t>
          <dl newline="false" spacing="normal">
            <dt>acl-name:</dt>
            <dd>
              <t>A name of an access list defined using
              the DOTS data channel (Section 4.3 of <xref
              target="RFC8783"></xref>) (<xref target="RFC8783"
	      sectionFormat="of" section="4.3"/>) that is associated with the DOTS
              client.<vspace blankLines="1" />As
              client.</t>
              <t>As a reminder, an ACL is an ordered list of Access Control
              Entries (ACE). (ACEs). Each ACE has a list of match criteria and a list
              of actions <xref
              target="RFC8783"></xref>. target="RFC8783" format="default"/>. The list
              of configured ACLs can be retrieved using the DOTS data channel
              during 'idle' time.<vspace
              blankLines="1" />This time.</t>
              <t>This is a mandatory attribute when 'acl-list'
              is included.</t>

              <t hangText="activation-type:">Indicates
            </dd>
            <dt>activation-type:</dt>
            <dd>
              <t>An attribute indicating the activation type of
              an ACL overriding the existing 'activation-type' installed by
              the DOTS client using the DOTS data channel. <vspace
              blankLines="1" />As </t>
              <t>As a reminder, this attribute can be set to
              'deactivate', 'immediate', or 'activate-when-mitigating' as
              defined in <xref target="RFC8783"></xref>. <vspace
              blankLines="1" />Note target="RFC8783" format="default"/>. </t>
              <t>Note that both 'immediate' and
              'activate-when-mitigating' have an immediate effect when a
              mitigation request is being processed by the DOTS server.
              <vspace blankLines="1" />This
              </t>
              <t>This is an optional attribute.</t>
            </list></t>
            </dd>
          </dl>

          <t>By default, ACL-related operations are achieved using the DOTS
          data channel protocol when no attack is ongoing. DOTS clients MUST
          NOT <bcp14>MUST
          NOT</bcp14> use the filtering control over the DOTS signal channel in 'idle'
          time; such requests MUST <bcp14>MUST</bcp14> be discarded by DOTS servers with 4.00 (Bad
          Request).</t>
          <t>During an attack time, DOTS clients may include 'acl-list',
          'acl-name', and 'activation-type' attributes in a mitigation
          request. This request may be the initial mitigation request for a
          given mitigation scope or a new one overriding an existing request.
          In both cases, a new 'mid' MUST <bcp14>MUST</bcp14> be used. Nevertheless, it is NOT
          RECOMMENDED <bcp14>NOT
          RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation
          request for a given mitigation scope or in a mitigation request
          adjusting the mitigation scope. This recommendation is meant to
          avoid delaying attack mitigations because of failures to process ACL
          attributes.</t>
          <t>As the attack evolves, DOTS clients can adjust the
          'activation-type' of an ACL conveyed in a mitigation request or
          control other filters as necessary. This can be achieved by sending
          a PUT request with a new 'mid' value.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe
          to asynchronous notifications of the attack mitigation, as detailed
          in Section
          4.4.2.1 of <xref target="RFC8782"></xref>. target="RFC8782" sectionFormat="of" section="4.4.2.1"/>. If
          not, the polling mechanism in Section 4.4.2.2 of <xref target="RFC8782"></xref> target="RFC8782"
          sectionFormat="of" section="4.4.2.2"/> has to be followed by the
          DOTS client.</t>
          <t>A DOTS client relies on the information received from the DOTS
          server and/or local information to the DOTS client domain to trigger
          a filter control request. Only filters that are pertinent for an
          ongoing mitigation should be controlled by a DOTS client using the
          DOTS signal channel.</t>
          <t>'acl-list', 'acl-name', and 'activation-type' are defined as
          comprehension-required parameters. Following the rules in Section 6
          of <xref target="RFC8782"></xref>,
          target="RFC8782" sectionFormat="of" section="6"/>, if the DOTS
          server does not understand the 'acl-list' or 'acl-name' 'acl-list', 'acl-name', or
          'activation-type' attributes, it responds with a "4.00 4.00 (Bad Request)"
          Request) error response code.</t>
          <t>If the DOTS server does not find the ACL name ('acl-name')
          conveyed in the mitigation request for this DOTS client, it MUST <bcp14>MUST</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
          assuming the request passed the validation checks in Section 4.4.1
          of <xref target="RFC8782"></xref>,
          target="RFC8782" sectionFormat="of" section="4.4.1"/>, the DOTS
          server MUST <bcp14>MUST</bcp14> proceed with the 'activation-type'
          update. The update is immediately enforced by the DOTS server and
          will be maintained as the new activation type for the ACL name even
          after the termination of the mitigation request. In addition, the
          DOTS server MUST <bcp14>MUST</bcp14> update the lifetime of the
          corresponding ACL similar to the update when a refresh request is
          received using the DOTS data channel (Section 7.2 of <xref
          target="RFC8783"></xref>). (<xref target="RFC8783"
          sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS
          server fails to apply the filter update, it MUST <bcp14>MUST</bcp14>
          respond with a 5.03 (Service Unavailable) error response code and
          include the failed ACL update in the diagnostic payload of the
          response (an example is shown in <xref target="diag"></xref>). target="diag"
          format="default"/>). Else, the DOTS server replies with the
          appropriate response code defined in Section 4.4.1 of <xref
          target="RFC8782"></xref>.</t>

          <t><figure align="center" anchor="diag"
              title="Example target="RFC8782"
          sectionFormat="of" section="4.4.1"/>.</t>
          <figure anchor="diag">
            <name>Example of a Diagnostic Payload Including Failed ACL Update">
              <artwork><![CDATA[{ Update</name>
<sourcecode>
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "mid": 123,
        "ietf-dots-signal-control:acl-list": [
          {
            "acl-name": "an-accept-list",
            "activation-type": "deactivate"
          }
        ]
      }
    ]
  }
}]]></artwork>
            </figure></t>
}
</sourcecode>
          </figure>
          <t>The JSON/YANG mappings for DOTS filter control attributes are
          shown in Table 1. <xref target="table1"/>. As a reminder, the mapping for 'acl-name' is
          defined in Table 5 of <xref target="RFC8782"></xref>.</t>

          <t><figure>
              <artwork><![CDATA[+-------------------+------------+--------+---------------+--------+
| Parameter Name    | YANG       | CBOR   | CBOR Major    | JSON   |
|                   | Type       | Key    |    Type &     | Type   |
|                   |            |        | Information   |        |
+===================+============+========+===============+========+
| activation-type   | enumeration| TBA1   | 0 unsigned    | String |
+-------------------+------------+--------+---------------+--------+
| ietf-dots-signal- |            |        |               |        |
|  control:acl-list | list       | TBA2   | 4 array       | Array  |
+-------------------+------------+--------+---------------+--------+
| acl-name          | leafref    | 23     | 3 text string | String |
+-------------------+------------+--------+---------------+--------+
  Table 1: JSON/YANG target="RFC8782"/>.</t>

<table anchor="table1">
  <name>JSON/YANG Mapping to CBOR for Filter Control Attributes]]></artwork>
            </figure></t> Attributes</name>

  <thead>
    <tr>
      <th>Parameter Name</th>
      <th>YANG Type</th>
      <th>CBOR Type</th>
      <th>CBOR Major Type &amp; Information</th>
      <th>JSON Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>activation-type</td>
      <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
          diagnostic payload indicating a failed ACL update as a response to
          an initial mitigation or a mitigation with adjusted scope, the DOTS
          client MUST <bcp14>MUST</bcp14> immediately send a new request which that
          repeats all the parameters as sent in the failed mitigation request
          but without including the ACL attributes. After the expiry of
          Max-Age returned in the 5.03 (Service Unavailable) response, the
          DOTS client retries with a new mitigation request (i.e., a new
          'mid') that repeats all the parameters as sent in the failed
          mitigation request (i.e., the one including the ACL attributes).</t>
          <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
          ACL bound to a DOTS client, the DOTS server notifies that DOTS
          client of the change by including the corresponding ACL parameters
          in an asynchronous notification (the DOTS client is observing the
          active mitigation) or in a response to a polling request (Section
          4.4.2.2 of <xref target="RFC8782"></xref>).</t> (<xref
          target="RFC8782" sectionFormat="of" section="4.4.2.2"/>).</t>
          <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
          above request processing operations are undertaken using the
          coordination mechanism discussed in <xref target="bind"></xref>.</t> target="bind" format="default"/>.</t>
          <t>This specification does not require any modification to the
          efficacy update and the withdrawal procedures defined in <xref
          target="RFC8782"></xref>. target="RFC8782" format="default"/>. In particular, ACL-related clauses are not
          included in a PUT request used to send an efficacy update and DELETE
          requests.</t>
        </section>
        <section anchor="YANG" title="DOTS numbered="true" toc="default">
          <name>DOTS Signal Filtering Control Module "> Module</name>
          <section anchor="tree" title="Tree Structure"> numbered="true" toc="default">
            <name>Tree Structure</name>
            <t>This document augments the "ietf-dots-signal-channel" YANG
            module defined in <xref target="RFC8782"></xref> target="RFC8782" format="default"/> for managing
            filtering rules.</t>
            <t>This document defines the YANG module
            "ietf-dots-signal-control", which has the following tree
            structure:<figure>
                <artwork><![CDATA[module:
            structure:</t>

<sourcecode type="yangtree">
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>
              </figure></t>
</sourcecode >
          </section>
          <section title="YANG Module"> numbered="true" toc="default">
            <name>YANG Module</name>
            <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 this document. It serves only to provide a
            data model and encoding, but not a management data model.</t>
            <t>This module uses types defined in <xref
            target="RFC8783"></xref>.</t>

            <t><figure>
                <artwork><![CDATA[<CODE BEGINS> target="RFC8783" format="default"/>.</t>

<!-- [rfced] Please note that we have updated the format of the YANG module
using the formatting option of pyang. We have created the following diff
file "ietf-dots-signal-control@2019-05-13.yang" so you can view the changes. Let us know any objections.

https://www.rfc-editor.org/authors/ietf-dots-signal-control-format-diff.html
-->

 <sourcecode name="ietf-dots-signal-control@2020-09-10.yang" type="yang" markers="true"><![CDATA[
module ietf-dots-signal-control {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
  prefix dots-control;

  import ietf-dots-signal-channel {
    prefix ietf-signal;
    reference
      "RFC 8782: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Specification";
  }
  import ietf-dots-data-channel {
    prefix ietf-data;
    reference
      "RFC 8783: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Data Channel Specification";
  }

  organization
    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/dots/>
     WG List:  <mailto:dots@ietf.org>

     Author:  Kaname Nishizuka
              <mailto:kaname@nttv6.jp>

     Author:  Mohamed Boucadair
              <mailto:mohamed.boucadair@orange.com>

     Author:  Konda, Tirumaleswar Reddy
              <mailto:TirumaleswarReddy_Konda@McAfee.com>

     Author:  Takahiko Nagata
              <mailto:nagata@lepidum.co.jp>";

  description
    "This module contains YANG definition for the signaling
     messages exchanged between a DOTS client and a DOTS server
     to control, by means of the DOTS signal channel, filtering
     rules configured using the DOTS data channel.

     Copyright (c) 2020 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     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; 8909; see
     the RFC itself for full legal notices.";

  revision 2019-05-13 2020-09-10 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 8909: Controlling Filtering Rules Using Distributed
                 Denial-of-Service Open Threat Signaling (DOTS)
                 Signal Channel";
  }

  feature control-filtering {
    description
      "This feature means that the DOTS signal channel is able
       to manage the filtering rules created by the same DOTS
       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; "control-filtering";

    description
      "ACL name and activation type.";

    list acl-list {
      key "acl-name";
      description
        "List of ACLs as defined using the DOTS data
         channel. ACLs bound to a DOTS client are uniquely
         identified by a name.";
      leaf acl-name {
        type leafref {
          path "/ietf-data:dots-data/ietf-data:dots-client"
             + "/ietf-data:acls/ietf-data:acl/ietf-data:name";
        }
        description
          "Reference to the ACL name bound to a DOTS client.";
      }
      leaf activation-type {
        type ietf-data:activation-type;
        default "activate-when-mitigating";
        description
          "Sets the activation type of an ACL.";
      }
    }
  }
}
<CODE ENDS>
]]></artwork>
              </figure></t>
]]></sourcecode>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sample" title="Some Examples"> numbered="true" toc="default">
      <name>Some Examples</name>
      <t>This section provides some examples to illustrate the behavior
      specified in <xref target="filtering"></xref>. target="filtering" format="default"/>. These examples are
      provided for illustration purposes; they should not be considered as
      deployment recommendations.</t>
      <section anchor="sample1" title="Conflict Handling"> numbered="true" toc="default">
        <name>Conflict Handling</name>
        <t>Let's consider a DOTS client which that contacts its DOTS server during
        '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
        forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
        a PUT request as shown in <xref target="PUT"></xref>.</t>

        <t><figure anchor="PUT"
            title="DOTS target="PUT" format="default"/>.</t>
        <figure anchor="PUT">
          <name>DOTS Data Channel Request to Create a Filter">
            <artwork align="left"><![CDATA[PUT Filter</name>
<sourcecode>
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
    /acl=an-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "an-accept-list",
        "type": "ipv6-acl-type",
        "activation-type": "activate-when-mitigating",
        "aces": {
          "ace": [
            {
              "name": "test-ace-ipv6-udp",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/48"
                },
                "udp": {
                  "destination-port-range-or-operator": {
                    "operator": "eq",
                    "port": 443
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
</sourcecode>
        </figure>
        <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
        mitigation request to its DOTS server as shown in <xref
        target="mitigate"></xref>.</t>

        <t><figure anchor="mitigate"
            title="DOTS target="mitigate" format="default"/>.</t>
        <figure anchor="mitigate">
          <name>DOTS Signal Channel Mitigation Request">
            <artwork align="left"><![CDATA[Header: Request</name>
<sourcecode>
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:6401::2/127"
        ],
        "target-protocol": [
          17
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>The DOTS server accepts immediately accepts the request by replying with
        2.01 (Created) (<xref target="response"></xref> target="response" format="default"/> depicts the message
        body of the response).</t>

        <t><figure anchor="response" title="Status
        <figure anchor="response">
          <name>Status Response (Message Body)">
            <artwork align="left"><![CDATA[{ Body)</name>
<sourcecode>
{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "mid": 123,
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>Assuming the DOTS client subscribed to asynchronous notifications,
        when the DOTS server concludes that some of the attack sources belong
        to 2001:db8:1234::/48, it sends a notification message with 'status'
        code set to '1 1 (Attack mitigation is in progress)' progress) and
        'conflict-cause' set to '2' 2 (conflict-with-acceptlist) to the DOTS
        client to indicate that this mitigation request is in progress, but a
        conflict is detected.</t>
        <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
        as shown in <xref target="control"></xref>.</t> target="control" format="default"/>.</t>
        <t>The DOTS client can also decide to send a PUT request to deactivate
        the "an-accept-list" ACL, ACL if suspect traffic is received from an
        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>

        <t><figure anchor="control"
            title="PUT target="control" format="default"/>.</t>
        <figure anchor="control">
          <name>PUT for Deactivating a Conflicting Filter">
            <artwork align="left"><![CDATA[Header: Filter</name>
<sourcecode>
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=124"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:6401::2/127"
        ],
        "target-protocol": [
          17
        ],
        "ietf-dots-signal-control:acl-list": [
          {
            "acl-name": "an-accept-list",
            "activation-type": "deactivate"
          }
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>Then, the DOTS server deactivates the "an-accept-list" ACL and replies
        with a 2.04 (Changed) response to the DOTS client to confirm the
        successful operation. The message body is similar to the one depicted
        in <xref target="response"></xref>.</t> target="response" format="default"/>.</t>
        <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
        in <xref target="GET-2"></xref>, target="GET-2" format="default"/>, the activation type is set to
        'deactivate' as set by the DOTS signal channel (<xref
        target="control"></xref>) target="control" format="default"/>) instead of the type initially set using the
        DOTS data channel (<xref target="PUT"></xref>).</t>

        <t><figure anchor="GET-2"
            title="DOTS target="PUT" format="default"/>).</t>
        <figure anchor="GET-2">
          <name>DOTS Data Channel GET Response after Mitigation (Message Body)">
            <artwork align="left"><![CDATA[{ Body)</name>
<sourcecode>
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "an-accept-list",
        "type": "ipv6-acl-type",
        "activation-type": "deactivate",
        "pending-lifetime": 10021,
        "aces": {
          "ace": [
            {
              "name": "test-ace-ipv6-udp",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/48"
                },
                "udp": {
                  "destination-port-range-or-operator": {
                    "operator": "eq",
                    "port": 443
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
</sourcecode>
        </figure>
      </section>
      <section anchor="sample2"
               title="On-Demand numbered="true" toc="default">
        <name>On-Demand Activation of an Accept-List Filter"> Filter</name>
        <t>Let's consider a DOTS client which that contacts its DOTS server during
        '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
        does so by sending, for example, a PUT request shown in <xref
        target="PUT1"></xref>.
        target="PUT1" format="default"/>. The DOTS server installs this filter
        with a "deactivated" state.</t>

        <t><figure anchor="PUT1"
            title="DOTS
        <figure anchor="PUT1">
          <name>DOTS Data Channel Request to Create an Accept-List Filter">
            <artwork align="left"><![CDATA[PUT Filter</name>
<sourcecode>
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
    /acl=my-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "my-accept-list",
        "type": "ipv6-acl-type",
        "activation-type": "deactivate",
        "aces": {
          "ace": [
            {
              "name": "an-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:6401::2/127",
                  "source-ipv6-network": "2001:db8:1234::/48",
                  "protocol": 17
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>
}
</sourcecode>
        </figure>
        <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
        the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS
        client domain. Consequently, the DOTS client sends a mitigation
        request to its DOTS server as shown in <xref
        target="mitigate1"></xref>.</t>

        <t><figure anchor="mitigate1"
            title="DOTS target="mitigate1" format="default"/>.</t>
        <figure anchor="mitigate1">
          <name>DOTS Signal Channel Mitigation Request with a Filter Control">
            <artwork align="left"><![CDATA[Header: Control</name>
<sourcecode>
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
Uri-Path: "mid=4879"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:6401::2/127"
        ],
        "target-protocol": [
          17
        ],
        "ietf-dots-signal-control:acl-list": [
          {
            "acl-name": "my-accept-list",
            "activation-type": "immediate"
          }
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>The DOTS server activates the "my-accept-list" ACL and replies with
        a 2.01 (Created) response to the DOTS client to confirm the successful
        operation.</t>
      </section>

      <section anchor="sample3"
               title="DOTS numbered="true" toc="default">
        <name>DOTS Servers/Mitigators Lacking Capacity"> Capacity</name>
        <t>This section describes a scenario in which a DOTS client activates
        a drop-list or a rate-limit filter during an attack.</t>
        <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
        thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
        countermeasure whenever required. Installing the accept-list can be
        done by sending, for example, the PUT request shown in <xref
        target="rate"></xref>.
        target="rate" format="default"/>. The DOTS server installs this filter
        with a "deactivated" state.</t>

        <t><figure anchor="rate"
            title="DOTS
        <figure anchor="rate">
          <name>DOTS Data Channel Request to Create a Rate-Limit Filter">
            <artwork><![CDATA[PUT Filter</name>
<sourcecode>
PUT /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=OopPisZqo4SLv64TLPXrxA/acls\
    /acl=my-ratelimit-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "my-ratelimit-list",
        "type": "ipv6-acl-type",
        "activation-type": "deactivate",
        "aces": {
          "ace": [
            {
              "name": "my-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8:123::/48"
                }
              },
              "actions": {
                "forwarding": "accept",
                "rate-limit": "20000.00"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <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
        request to its DOTS server (<xref target="ratel"></xref>).</t>

        <t><figure anchor="ratel"
            title="DOTS target="ratel" format="default"/>).</t>
        <figure anchor="ratel">
          <name>DOTS Signal Channel Mitigation Request">
            <artwork><![CDATA[Header: Request</name>
<sourcecode>
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=85"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:123::/48"
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>For some reason (e.g., the DOTS server, or the mitigator, is
        lacking a capability or capacity), the DOTS client is still receiving
        attack traffic traffic, which saturates available links. To soften the
        problem, the DOTS client decides to activate the filter that
        rate-limits the traffic destined to the DOTS client domain. To that
        aim, the DOTS client sends the mitigation request to its DOTS server
        shown in <xref
        target="rateres"></xref>.</t>

        <t><figure anchor="rateres"
            title="DOTS target="rateres" format="default"/>.</t>
        <figure anchor="rateres">
          <name>DOTS Signal Channel Mitigation Request to Activate a Rate-Limit Filter">
            <artwork><![CDATA[Header: Filter</name>
<sourcecode>
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=86"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:123::/48"
        ],
        "ietf-dots-signal-control:acl-list": [
          {
            "acl-name": "my-ratelimit-list",
            "activation-type": "immediate"
          }
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
        <t>Then, the DOTS server activates the "my-ratelimit-list" ACL and replies
        with a 2.04 (Changed) response to the DOTS client to confirm the
        successful operation.</t>
        <t>As the attack mitigation evolves, the DOTS client may decide to
        deactivate the rate-limit policy (e.g., upon receipt of a notification
        status change from 'attack-exceeded-capability' to
        'attack-mitigation-in-progress'). Based on the mitigation status
        conveyed by the DOTS server, the DOTS client can de-activate deactivate the
        rate-limit action. It does so by sending the request shown in <xref
        target="rateres2"></xref>.</t>

        <t><figure anchor="rateres2"
            title="DOTS target="rateres2" format="default"/>.</t>
        <figure anchor="rateres2">
          <name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter">
            <artwork><![CDATA[Header: Filter</name>
<sourcecode type="cbor">
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=87"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "target-prefix": [
          "2001:db8:123::/48"
        ],
        "ietf-dots-signal-control:acl-list": [
          {
            "acl-name": "my-ratelimit-list",
            "activation-type": "deactivate"
          }
        ],
        "lifetime": 3600
      }
    ]
  }
}
]]></artwork>
          </figure></t>
</sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">

<!-- [rfced] Would it be helpful to update these section titles as follows? Both
are subsctions in the IANA Considerations section.

Original:
   5.1.  DOTS Signal Channel CBOR Mappings Registry
   5.2.  DOTS Signal Filtering Control YANG Module

Perhaps: ("Key Values" rather than "Mappings"; "Signal Control" rather than
"Signal Filtering Control"):
   5.1.  DOTS Signal Channel CBOR Key Values Subregistry
   5.2.  DOTS Signal Control YANG Module
-->

      <name>IANA Considerations</name>
      <section anchor="map" title="DOTS numbered="true" toc="default">
        <name>DOTS Signal Channel CBOR Mappings Registry">
        <t>This specification registers Registry</name>
        <t>Per this specification, IANA has registered the following parameters in the IANA
        "DOTS Signal Channel CBOR Key Values" registry <xref
        target="Key-Map"></xref>.</t>

        <t><list style="symbols">
            <t>Note to the RFC Editor: Please delete (TBA1-TBA2) once the CBOR
            keys are assigned from subregistry within the 1-16383 range. Please update Table 1
            accordingly.</t>
          </list></t>

        <t><figure align="center">
            <artwork><![CDATA[   +--------------------+--------+-------+------------+---------------+
   | Parameter Name     | CBOR   | CBOR  | Change     | Specification |
   |                    |
	"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel" registry <xref target="Key-Map" format="default"/>.</t>

<table anchor="table2">

  <thead>
    <tr>
      <th>Parameter Name</th>
      <th>CBOR Key    | Value</th>
      <th>CBOR Major | Controller | Document(s)   |
   |                    | Value  | Type  |            |               |
   +====================+========+=======+============+===============+
   | activation-type    |   52   |       |            |               |
   |                    | (TBA1) |   0   |    IESG    |   [RFCXXXX]   |
   +--------------------+--------+-------+------------+---------------+
   | ietf-dots-signal-  |   53   |       |            |               |
   |   control:acl-list | (TBA2) |   4   |    IESG    |   [RFCXXXX]   |
   +--------------------+--------+-------+------------+---------------+
]]></artwork>
          </figure></t> Type</th>
      <th>Change Controller</th>
      <th>Specification Document(s)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>activation-type</td>
      <td>52</td>
      <td>0</td>
      <td>IESG</td>
      <td>RFC 8909</td>
    </tr>
    <tr>
      <td>ietf-dots-signal-control:acl-list</td>
      <td>53</td>
      <td>4</td>
      <td>IESG</td>
      <td>RFC 8909</td>
    </tr>

  </tbody>
</table>

      </section>
      <section anchor="yang-iana"
               title="DOTS numbered="true" toc="default">
        <name>DOTS Signal Filtering Control YANG Module">
        <t>This document requests IANA to register Module</name>
        <t>IANA has registered the following URI in the
        "ns" subregistry within the "IETF XML Registry" <xref
        target="RFC3688"></xref>:</t>

        <t><figure>
            <artwork><![CDATA[  URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
  Registrant Contact: The IESG.
  XML: N/A; target="RFC3688" format="default"/>:</t>

<dl newline="false" spacing="compact">
<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.

]]></artwork>
          </figure></t>

        <t>This namespace.</dd>
</dl>

<!-- [rfced] We have updated the citation in the following sentence for the
"YANG Module Names" registry from [RFC7950] to [RFC6020] as RFC 6020 is
the RFC that defines the registry (see
https://www.iana.org/assignments/yang-parameters/).  Also, we have placed
the reference entry for RFC 6020 in the Normative References
section. Please let us know if it should be informative instead.

Original:
   This document requests IANA to register the following YANG module in the
   "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters"
   registry.
-->
        <t>IANA has registered the following YANG module
        in the "YANG Module Names" subregistry <xref target="RFC7950"></xref> target="RFC6020" format="default"/>
        within the "YANG Parameters" registry.</t>

        <t><figure>
            <artwork><![CDATA[  Name: ietf-dots-signal-control
  Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
  Maintained by IANA: N
  Prefix: dots-control
  Reference: RFC XXXX

]]></artwork>
          </figure></t>

<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ietf-dots-signal-control</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
<dt>Maintained by IANA:</dt><dd>N</dd>
<dt>Prefix:</dt><dd>dots-control</dd>
<dt>Reference:</dt><dd>RFC 8909</dd>
</dl>
      </section>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>The security considerations for the DOTS signal channel protocol are
      discussed in Section 10 of <xref target="RFC8782"></xref>, target="RFC8782" sectionFormat="of" section="10"/>,
      while those for the DOTS data channel protocol are discussed in Section 10 of <xref
      target="RFC8783"></xref>.
      target="RFC8783" sectionFormat="of" section="10"/>. The following
      discusses the security considerations that are specific to the DOTS
      signal channel extension defined in this document.</t>
      <t>This specification does not allow to create the creation of new filtering rules,
      which is the responsibility of the DOTS data channel. DOTS client
      domains should be adequately prepared prior to an attack, e.g., by
      creating filters that will be activated on demand when an attack is
      detected.</t>
      <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
      DOTS clients of the same DOTS client domain. As a reminder, DOTS servers
      must associate filtering rules with the DOTS client that created these
      resources. Failure to ensure such association by a DOTS server will have
      severe impact on DOTS client domains.</t>
      <t>A compromised DOTS client can use the filtering control capability to
      exacerbate an ongoing attack. Likewise, such a compromised DOTS client
      may abstain from reacting to an ACL conflict notification received from
      the DOTS server during attacks. These are not new attack vectors, but
      variations of threats discussed in <xref target="RFC8782"></xref> target="RFC8782"
      format="default"/> and <xref target="RFC8783"></xref>. target="RFC8783" format="default"/>. DOTS
      operators should carefully monitor and audit DOTS agents to detect
      misbehaviors and to deter misuses.</t>
    </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>
  <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 ?>

<displayreference target="I-D.ietf-dots-architecture" to="DOTS-ARCH"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8782.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/>
      </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'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-architecture.xml"/>

        <reference anchor="Interop" anchor="INTEROP" target="https://datatracker.ietf.org/meeting/103/materials/slides-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>
                  <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>
                  <street/>
                  <city/>
                  <region/>
                  <code/>
                  <country/>
                </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
                <phone/>
                <email/>
                <uri/>
              </address>
            </author>
            <author fullname="Liang Xia" initials="L." surname="Xia ">
              <organization>Huawei</organization>
              <address>
                <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
                  <street/>
                  <city/>
                  <region/>
                  <code/>
                  <country/>
                </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
                <phone/>
                <email/>
                <uri/>
              </address>
            </author>
            <date month="November" year="2018" /> year="2018"/>
          </front>
        </reference>

        <reference anchor="Key-Map"
                 target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values"> target="https://www.iana.org/assignments/dots">
          <front>
          <title>DOTS
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS)
	    Signal Channel CBOR Key Values</title> Channel</title>
            <author fullname="IANA">
            <organization></organization>
              <organization/>
            </author>

          <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>

<!-- [rfced] Please review the sourcecode elements in the XML file. Should any
of these be artwork or something else instead? If they should remain
sourcecode, please review whether the "type" attribute should be set.  If
the current list of preferred values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
contain an applicable type, then feel free to suggest a new one.  Also,
it is acceptable to leave the "type" attribute not set.

Note that the "type" attribute has been set for some sourcecode elements;
please review these to confirm that they are correct.
-->

<!-- [rfced] Terminology

a) Please review the use of "accept-listed" and "accept-list" when used as an
adjective before a noun. We see the following uses in the document and
question if these should be consistent. Let us know if any updates are needed.

accept-listed traffic
accept-listed sources
accept-listed filtering rules

accept-list rules
accept-list filter

b) We note inconsistencies in the term below throughout the text.  Should
the usage be uniform? If so, please let us know which form is preferred.

idle time vs. 'idle' time
-->

</rfc>